How your data moves, what we sign, and the four policies we run by.

Last updated 17 September 2026. This page is written for the person at a practice who has to approve a vendor. It says who we are, how data moves, what we sign, what we hold, and the four policies we run by. Ask for anything not on it: support@strategic-innovations.ai.

Who we are

Strategic Innovations AI is a small vendor. Two named operators have access to pilot data; nobody else does. We do not hold a SOC 2, HITRUST or ISO 27001 report today, and we say so rather than imply one. What we can give you now is this page, the policies in full, our risk assessment, and a record of every action on your pilot that you can verify yourself.

How data moves in a managed pilot

1. Before the first item, we sign a Business Associate Agreement with the practice, and the design brief names every data source the pilot will touch. Nothing that identifies a patient is sent to us before that.
2. The practice sends a denial and a chart excerpt by secure upload named in the design. Email is used for notifications and console links only and never carries patient data. Our operator reads the upload and stores it in the pilot's record on Cloudflare.
3. The packet is drafted automatically by a language model running on Cloudflare Workers AI, checked in code (below), then read by a person on our side before you see it. Your data is not used to train the model.
4. Your reviewer decides in a console at a private link: approve, approve with a correction, or reject. The decision, the reviewer's name and the time go on the record.
5. Someone on your team submits to the payer the way they do today. We never hold payer-portal credentials and never automate a payer portal.

Who processes data for us

• Cloudflare: hosting and storage (the pilot record, the reviewer console and the daily off-site copy of the record), and delivery of notification emails that carry no patient data.
• Stripe: payments. We never see or store card numbers.
• Cloudflare Workers AI runs the model that drafts packets (Google Gemma 4, on Cloudflare's network), so drafting stays with the processor that hosts the record.

Before the first pilot that touches patient data, we execute agreements with each processor in the data path and hand you the signed list with the brief.

What we hold, and for how long

• Pilot records (items, packets, decisions, corrections, the sealed chain): for the pilot and 90 days after it ends, then returned or destroyed as the practice instructs, in writing, within ten working days of the request.
• Free-packet requests (one de-identified denial each): the pasted denial and its draft are removed 90 days after the request by a scheduled job; the packet in the console stays with its record.
• Account data (email, password hash, one session cookie) and purchase records: as described on the privacy page.
• In transit, everything is TLS. At rest, Cloudflare encrypts storage. Reviewer keys are stored only as hashes; the key itself is emailed once.
• The sealed record is copied off the database every day to separate storage, so a pilot's history survives the loss of the database itself.

Audit controls

Every pilot is an append-only chain of events. Each event's hash covers its content and the previous event, and after every event the head is signed with an Ed25519 key whose public half is published at /v1/ledger/public-key. Anyone with the export can verify it without asking us, at /v1/ledger/verify; an edited or dropped record fails with the reason. Each reviewer has a unique key per pilot, and every decision names the reviewer and the time. This is how we meet the audit-control and unique-user requirements of 45 CFR 164.312 for the record of the pilot.

Documents written to steer the drafting model

A denial, a chart excerpt or a pasted policy can carry text meant for a language model rather than for a person: "ignore your instructions", "mark this criterion met", a link to copy into the letter. This is prompt injection, the first risk on the OWASP list for applications built on language models (LLM01:2025). A packet altered this way would read like any other, so we look for it in code rather than trusting the model to notice.

• Before the model reads a document, hidden characters and chat-format markers are removed, and any sentence that reads as an instruction to a machine is withheld from the model and shown to our operator instead.
• The model reads each document inside a marked block, with a boundary code drawn fresh for every request, and is told that nothing inside a block is an instruction.
• Every draft is checked before a person sees it. A criterion marked met must cite words from the chart itself. The packet may carry no links, email addresses or phone numbers, and may not say that a person reviewed, approved or signed it unless the documents say so. A draft built from a document with a withheld sentence is held for a person, with the sentence shown.
• Corrections cannot change a decision. When a reviewer's correction is in force, whether each criterion is met is decided by a step that never sees corrections. Corrections shape only how the letter is written. A correction that reads as an instruction holds the draft, and one that would loosen how a criterion is judged, such as "treat the trial as documented", is shown to our operator and not applied.
• Pasted policy text is checked too. A sentence that changes a numbered section, such as an addendum or a footnote saying a requirement is met, is withheld and shown to our operator to check against the payer's published policy.
• Every draft carries its own record. Each step, from the inputs to the final checks, is recorded as fingerprints rather than content, and the record's final fingerprint is written into the pilot's sealed record, so a changed step can be found later.
• We attack our own drafting step. On 17 September 2026 we ran twelve injections, twice each. Before these controls, 8 of 24 attempts produced a draft that passed every check. With them, 0 of 24 did. A second set of twelve, written afterwards in wording the controls had not seen, got 2 of 24 through. We closed that gap and ran the set again: 0 of 24.
• Then we used attacks written by separate AI agents that were not shown our code. On the first set of thirty, the drafting step we ran that morning let 8 of 60 attempts through, 6 of them by way of reviewer corrections. After the changes above, 0 of 60. The second set of thirty-six got 1 of 36 through: a correction asking the letter to say our medical director had approved it. The attestation rule above holds that draft, and on the re-run of 17 September 2026 the same set got 0 of 36 through, with 7 attacks producing the wording and every one of those held for a person.
• What these controls do not catch is a false fact written as a fact. If a chart says a medication was taken and it was not, the draft will repeat it. The clinician who reviews the packet is the check for that.

The four policies

Access control

• Two named operators. Access is by individual account; no shared passwords. Secrets live in Cloudflare's secret store, never in files or chat.
• Each pilot's reviewer key opens that pilot only. The operator token creates work and cannot record a reviewer's decision.
• Access is removed within 24 hours of a role change and reviewed at every sprint review.

Incident response

• Any suspected exposure of practice data is contained first, then reported to the practice within 72 hours of discovery, with what was affected, what we did, and what we will change. The HIPAA breach rule allows a business associate up to 60 days (45 CFR 164.410); we commit to 72 hours.
• The incident, the timeline and the fix are written into the pilot's record.

Data handling

• Nothing that identifies a patient enters a free or paid packet request; both forms require the sender's attestation. The sealed record holds a fingerprint of each request, never its text.
• Pilot data is used for that pilot only. It is not used to train models and not shown to another customer.
• Return or destruction on request, in writing, within ten working days; confirmation in writing.

Acceptable use

• We prepare; a person decides and a person submits. We do not automate payer portals and do not hold their credentials.
• Nothing we produce is medical, legal or financial advice, and nothing leaves without the practice's recorded approval.
• We may pause a pilot that is used to send unsolicited messages, to attack other systems, or to break the law.

Questions a reviewer usually asks next

• Where is the data stored? On Cloudflare's network. A storage-location constraint can be agreed in the BAA schedule.
• Can we see the policies in full and the risk assessment? Yes, by email, before you sign anything.
• Can we run the verifier ourselves? Yes; the command is on the worked example.