Applied AI

Before selling AI, we run it on ourselves.

Anyone offering AI systems to a medical practice should already be living with them. Here is the list of the ones we use on our own work every day: what they are for, who controls them and where they stop.

Request an assessment Explore the method

Page updated on 20 September 2026.

Why this page exists

An AI supplier who does not use AI is just a reseller.

In our field it is easy to talk about automation and work by hand. We took the opposite route: the same systems we propose to medical practices carry our own daily work, with the same boundaries. When something does not hold, we are the first to notice.

The systems

Six internal systems, each with its limit.

For each one: the problem it solves, how it works, where a person steps in and what it does not cover. None of these is a demo-day prototype.

A model writes the draft, a person publishes it

Problem: Replying to every review and preparing recall messages takes time, and time runs short exactly when the workload grows.
How it works: From our internal console a language model prepares the draft: a reply to a review, a recall message, a front-desk text. It stays a proposal until a person approves it.
Human control: No draft goes out on its own. Reviewing and publishing always belong to whoever follows the practice.
Stated limit: If the model service is unavailable the console says so and the draft is written by hand: work does not stop, but it does not continue automatically either.

Healthcare rules live in the code, not only in the prompt

Problem: A text can look harmless and still contain a discount, a promise of results, or an implicit confirmation that the person who wrote is a patient of the practice.
How it works: Every generated text goes through a separate check that looks for discounts and promotions, promises of results and absolute superlatives, clinical terms and phrases confirming a doctor-patient relationship. The flags appear next to the text, before publication.
Human control: The check warns, it does not decide: the final call stays with a person, who reads the flags alongside the draft.
Stated limit: It is a check on words and phrases, not a legal opinion. It does not replace reading by someone who knows the case.

We run the front-desk assistant on ourselves first

Problem: A virtual assistant that steps outside its scope is not a cosmetic defect: in healthcare it is a risk.
How it works: Before we propose it, the assistant runs in our console with the configuration of a test practice. Its instructions are built server side only. After each reply a second check re-reads the text: if it drifts into clinical advice, the reply is replaced with a message that hands the request back to the practice.
Human control: Only outcomes are logged, never the text of the messages. The practice configuration is not decided by the model.
Stated limit: The scope does not change with the place the assistant runs in: logistics and organisation, never clinical guidance. A public chat, when it is active, follows the same rules plus the ban on discussing prices, which are defined after the assessment.

A request from the site rings the owner’s phone

Problem: Someone who writes to a supplier and gets no quick answer usually writes to another one. That is true for medical practices and it is true for us.
How it works: Every request sent from the site is stored and, at the same moment, triggers an alert to the owner on two independent channels. Whoever wrote receives a confirmation email describing what happens next, with no promised timeline.
Human control: A person calls back. No system answers in their place.
Stated limit: Alerts can never make the submission fail: if a channel is down, the request is still saved and visible in the console.

Before publishing, the site checks itself

Problem: A bad change on a page is noticed late, and in the meantime that page stays online as it is.
How it works: Every change goes through a full build and three layers of automated tests (unit, API, browser), then a check that calls every page listed in the sitemap and a visual audit at phone, tablet and desktop widths. A dedicated test verifies that each Italian page with an English twin declares the other one.
Human control: No line goes live before those checks have been run and read.
Stated limit: Tests tell you whether a page works, not whether it is well written. Judging the text stays human.

This site is written for readers without eyes, too

Problem: Search engines and AI assistants read pages without seeing them: if the information is not declared in a readable way, it gets reconstructed by guesswork.
How it works: The site publishes a summary file for AI assistants, structured data on every page (organisation, services, frequently asked questions, navigation path), Italian-English correspondences generated from a single list shared by pages and sitemap, and update dates taken from the real files instead of from today’s date.
Human control: Notifications to search engines run in simulated mode: without an explicit command the system prints what it would send and sends nothing.
Stated limit: The instant-notification protocol is used by some engines, not by Google: for Google it is still sitemap and crawling.

The boundaries

What we do not let the AI do.

These lines are not good intentions: they are constraints written into the code or working rules already in force. They apply to us and to the systems we deliver.

It publishes nothing by itself: reviews, messages and pages go out after a person.
It never receives patient data. In recall messages the name is added by the sending platform, not by the model.
It does not answer health questions. If a reply tries to, it is replaced and the request goes back to the practice.
It does not set prices or terms: those are defined after the assessment, talking to the practice.
It does not invent numbers. If a figure is not verified, it leaves the page instead of being rounded.
It never writes reviews and never confirms in public that a person is a patient of the practice.

Where we work

Born in Italy, built to work remotely.

Studio Bonanno Consulting is an Italian business based in Mazara del Vallo (TP). Almost all the work happens remotely: analysis, design and configuration take place inside the systems of the practice, not in its waiting room. That makes distance an organisational detail rather than an obstacle.

The site lives in two languages, Italian and English, with the versions declaring each other and Italian as the reference. The English perimeter is a selection of pages, not the full translation: we prefer saying so to making the site look bigger than it is.

The constraints of Italian healthcare communication remain the yardstick in English too: no promise of results, no public discounts, no selectively solicited reviews.

Where it continues

The same principles, applied to your practice.

MethodThe six phases, from analysis to measurement.SolutionsThe three systems and custom development.Claudia AIThe virtual front desk and its logistical scope.AboutWho is behind this and why healthcare only.

Frequently asked questions

The questions we get about this page.

Do you use AI to write the copy on this site?

Yes, as a drafting tool. Then every statement is checked against its source and whatever does not hold up is removed rather than softened: that is why you will not find percentages, client counts or success stories on these pages. Andrea Bonanno is responsible for what you read.

Does the AI answer patients instead of the practice?

No. The assistant handles logistics and organisation only: hours, location, how to book, reminders. Diagnosis, triage and clinical advice stay with the people of the practice. The same applies to us: an assistant on the site answers about services, method and how to get in touch, and hands the request to a person as soon as the question leaves that scope.

What happens when the model gets it wrong?

We treat that as a normal case, not an exception. That is why the checks sit outside the model: a second pass re-reads the text, flags what is off and, where needed, replaces the reply with a hand-off to the practice. Nothing goes out before a person has seen it.

Does patient data pass through the AI?

No. Recall messages are generic and written for a campaign, not for a person: the model only receives the practice name, the campaign criteria, the channel and the tone notes. The recipient name is added by the sending platform.

Do you work outside Italy?

We work remotely, in Italian and in English: the site exists in both languages, with the pages declaring each other, and Italian remains the reference version. The business is registered in Italy, in Mazara del Vallo (TP).

Why publish the limits as well?

Because a system whose boundaries are unknown cannot be assessed. In healthcare that matters more than a list of features: knowing where a system stops is what tells you whether it is worth activating.

Want to see how this would apply to your practice?

It starts with the analysis: what already works, what gets lost along the way, what is worth automating and what is not.

Request an assessment See the solutions