|
SAMPLE
DeployerProof
Compliance gap report · Demonstration AI Transparency Gap Report
|
| Touchpoint | Surface | Your role | Live since | In scope |
|---|---|---|---|---|
| Support chat assistant | Web app widget | Deployer | Mar 2025 | YES |
| Marketing-site chatbot | Public website | Deployer | Nov 2025 | YES |
| AI-drafted onboarding emails | Deployer + content publisher | Jun 2026 | YES | |
| “Ask AI” in-app answer box | Web app | Deployer | Feb 2026 | YES |
| Meeting-notes summariser | Web app + export | Deployer + content publisher | Private beta · GA Sept 2026 | PENDING |
| Docs semantic search | Web app + help centre | — | 2024 | N/A |
Docs semantic search is out of scope: it ranks and returns extracted passages from existing help articles with source links, and generates no new text. Retrieval without synthesis does not engage Article 50. · Deepfake-class content under Art. 50(4): none found. Acme produces no realistic imagery, audio or video of people, places or events, and no synthetic voice. Recorded here so the question is answered rather than left open.
| Touchpoint | Obligation | Status | Finding |
|---|---|---|---|
| Support chat assistant | Art. 50(1) — interaction disclosure | GAP | The widget is titled “Acme Support”, uses an illustrated human avatar, and opens with “Hi! How can I help today?” — nothing states that the responder is an AI system. The only AI wording is “Powered by AI” in the launcher's hover tooltip, which never renders on touch devices and is not visible before the first exchange. The obviousness carve-out does not carry this: a generic support label plus a human avatar points a reasonable user the other way. The disclosure is also absent in the German and French interfaces, where the widget is served today. |
| Marketing-site chatbot | Art. 50(1) — interaction disclosure | GAP | Same underlying assistant, embedded on the public site as “Chat with us”, with no AI disclosure of any kind. This surface sits with the marketing team rather than product, which is usually why it is missed — it is nonetheless the first AI interaction most EU visitors have with Acme. |
| “Ask AI” answer box | Art. 50(1) — interaction disclosure | PARTIAL | The English label “Ask AI” is explicit, sits directly on the input, and in our reading meets the obligation on its own. The German build renders the same control as “Fragen” and the French as “Poser une question”; both drop the AI signal entirely. The gap is localisation, not design. |
| AI-drafted onboarding emails | Art. 50(1) — interaction disclosure | N/A | No natural person interacts with the AI system here. The email is one-way generated content, not a conversational exchange, so 50(1) is not the operative provision — 50(2) is. Recorded because this is the most common misreading we see, and because a questionnaire answer benefits from the reasoning. |
| AI-drafted onboarding emails | Art. 50(2) — machine-readable marking | PARTIAL | Synthetic text that leaves the product and lands in an inbox. No marking of any kind is applied today. The sequence went live in June 2026, before 2 August 2026, so the transition applies and the deadline is 2 December 2026. Deadline-bound rather than live exposure. |
| Support chat assistant | Art. 50(2) — machine-readable marking | PARTIAL | Replies inside the widget stay in the conversation surface, but the “email me this conversation” feature sends generated text out of the product as a standalone document. That export path carries the marking obligation even though the live chat does not. Same 2 December 2026 deadline. Note the role question here: Acme is a deployer of OpenAI's model but the publisher of this output, and the marking duty follows the publishing. |
| “Ask AI” answer box | Art. 50(2) — machine-readable marking | N/A | Answers render in-session and cannot currently be exported or published. Not engaged today — but the “save answer to a workspace doc” item on your roadmap would change that, and it is cheaper to design the marking in now than to retrofit it. |
| Meeting-notes summariser | Art. 50(2) — machine-readable marking | GAP | Generates summaries that are shared into workspaces and exported as PDF. Because it reaches the market after 2 August 2026, the transition period does not apply: marking has to be in place at launch, not by December. This is the single item where a slipped decision turns into a launch blocker. |
| All generative surfaces | Art. 50(4) — AI-generated text and deepfakes | N/A | Acme publishes no AI-generated text to inform the public on matters of public interest, and produces no deepfake-class content. Output is either addressed to an identified user or confined to a customer's own workspace. Revisit if the AI-written changelog or blog drafts under discussion ship. |
| Support chat assistant · marketing chatbot | Evidence of disclosure history | GAP | The in-app widget's copy lives in a React component with real git history, which is partial evidence at best — no one has mapped a commit to what a user actually saw on a given date. The marketing widget is configured in the site builder with no version history at all. Neither answers “what did your disclosure say on 12 March, and prove it.” |
| Email and “Ask AI” surfaces | Evidence of disclosure history | PARTIAL | Prompt templates are versioned in git, so the generation side is traceable. What is not recorded is which template version produced which send, or when disclosure wording changed relative to the sends it applied to. |
Applied to the states Acme actually serves. The not-applicable rows carry their reasoning because that reasoning is what you paste into a questionnaire — and because the next person to ask will not accept “our lawyer said it's fine” without one.
| Statute | Status | Assessment |
|---|---|---|
| California SB 243 — companion chatbots | N/A | Neither assistant is companion-class. Both are task-scoped, hold no persistent persona, carry no relational or emotional framing, and drop context between sessions. The statute targets systems that sustain an ongoing relationship with a consumer; a support bot that answers a billing question and forgets you is not that. Revisit if the “AI teammate” persona concept ships with persistent memory. |
| California SB 942 / AB 853 — provider marking | N/A | Binds providers of generative AI systems with more than one million monthly users. Acme is a deployer of a third-party model, not a covered provider, and reports roughly 40,000 monthly users. Recorded because it is the California law people have usually read about, and answering it up front saves a round of questions. |
| Utah AI Policy Act | N/A | Not triggered at scan date — Acme reports no Utah-domiciled customers and operates in no regulated occupation the Act tightens. The obligation that would attach first is disclosure on request, which is inexpensive to pre-implement; note it as a trigger rather than a task. |
| Colorado SB 26-189 | N/A | No Colorado consumer base identified at scan date. The consumer-facing interaction disclosure duties are close in substance to what Article 50(1) already requires, so closing the EU gaps below largely pre-answers this one if Colorado users arrive. |
Trigger to re-run this section: first customer domiciled in a state not assessed above, or any change that gives an assistant a persistent persona or memory across sessions.
Ordered by exposure and effort, not by how interesting they are. Every effort figure is engineering time for one developer who already knows the codebase.
Put the disclosure in the widget header, where it stays visible for the whole session, and repeat it as the assistant's first message so it cannot be scrolled past or missed by a user who opens the widget from a deep link. It has to be present at or before the first exchange, not after the first reply, and it has to be in the language the interface is served in. Replace the illustrated human avatar on the assistant's messages — it actively works against the disclosure. Ship the German and French strings in the same release rather than as a follow-up; a disclosure that exists only in English is a gap in the markets where you have EU users.
Effort: ~40 min including the two locales. No backend change.
Same fix, different team. The embed is configured in the site builder, so this is a copy change rather than a deploy. Rename the launcher from “Chat with us” to something that carries the AI signal, and set the opening message to disclose before the visitor types. Whoever owns the marketing site should own this string going forward, and it should be on the release checklist for site rebuilds — this is the surface most likely to silently lose its disclosure in a redesign.
Effort: ~20 min, no engineering involvement.
The English control is fine as it stands. The translations dropped the operative word, which means the obligation is met for your English users and not for your German and French ones. Fix the two strings, and add a note to the localisation guide that the AI term is functional rather than stylistic and must survive translation.
Effort: ~30 min including a pass over neighbouring strings.
Two mechanisms are available today and they answer different questions. A structured header on the outbound message is machine-readable, survives most mail transfer agents, and is ignored harmlessly by clients that do not understand it. A line in the message body is human-readable and always visible. The operative requirement in Article 50(2) is the machine-readable one, so the body line is not a substitute — but shipping both is cheap and hedges the interpretation risk while the technical standards settle. Apply it at the send layer rather than per template, so new sequences inherit the marking instead of needing to remember it. Record the decision and the date you made it; that record is what you show when someone asks how you interpreted the requirement.
Effort: ~half a day at the send layer, plus a decision meeting on the header format.
The live chat surface does not trigger marking; the export does, because it turns the conversation into a document that leaves the product. Reuse whatever mechanism you settle on for onboarding email so this is a configuration rather than a second design. Worth noting the boundary in your own documentation, because the distinction between an in-session reply and an exported artefact is exactly the kind of thing that gets lost when the next engineer touches this code.
Effort: ~2h once the email marking decision is made.
This is the one with a hard edge. Systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the marking obligation; a system launching in September 2026 does not, and has to be marked from its first public release. Add marking to the beta now, while the surface area is small and the users are friendly, and treat it as launch criteria rather than a fast-follow. If the GA date moves earlier, this moves to P1.
Effort: ~1 day inside the existing beta work. Considerably more if retrofitted after launch.
Start manually and start today: move every disclosure string — widget header, opening message, marketing embed, email body line — into one file in the app repository, and require that changes to it go through a commit with a message stating what changed and where it renders. That single move converts scattered copy into a dated, reviewable history, and it takes an afternoon. The marketing-site string is the hard one, since the site builder has no version history; mirror it into the same file and treat the file as the source of truth.
If maintaining that discipline manually turns out to be the part that slips, our evidence-log service keeps the same record automatically with hash-chained, independently timestamped entries. That is optional, and the manual path above genuinely works — it is stated first for that reason.
Effort: ~3h to consolidate, then a habit rather than a task.
No work is required today. What is required is knowing when work becomes required: the first customer in a state you have not assessed, and any product decision that gives an assistant a persistent persona or memory across sessions. Write those two triggers down next to whoever owns compliance, and re-run this section when one fires.
Effort: ~15 min.
The inventory in section 2 answers the question that opens almost every AI section of a vendor security questionnaire — list your AI systems, what they do, and who provides the underlying model. Section 3 answers the follow-up about how users are informed. Section 4 is what you send when a US buyer's counsel asks which state laws you have looked at, and the not-applicable reasoning is the part that ends the thread rather than extending it.
Hand sections 1 through 4 to your counsel; the mapping work is done, so what they are reviewing is judgment rather than discovery. Hand section 5 to your engineering lead as written — the fixes are scoped to be picked up without further translation. On Monday morning the highest-value single action is the chat assistant disclosure, because it is forty minutes of work on the surface with the most EU users on it.
What this report does not do is tell you that you are compliant. No gap was identified against the published guidelines for the surfaces marked N/A above, on the evidence reviewed on the date shown. That is a different and more honest statement, and it is the one your counsel can actually work with.
The scan reviewed the product as a user sees it: the web application in English, German and French, the public marketing site, the onboarding email sequence as received, and the descriptions of the meeting-notes beta provided at intake. It ran against our standard checklist, which is built from the Commission's Article 50 guidelines of 20 July 2026, the Code of Practice on Transparency of 10 June 2026, and the state statutes as enacted.
Three limits worth stating plainly. We reviewed the surfaces, not the source code, so a feature that generates output without exposing it in the interface would not have been found. Findings are accurate as of the report date and this area is moving; the marking deadline in December is a fixed point, but guidance around it is still settling. And the German and French draft text in section 5 is machine-drafted — it is a starting point for a native reviewer, not production copy.
No conversation content, user records, or personal data of Acme's end users was collected, requested, or stored at any point in this scan. Obligations attach to configuration and surfaces, not to what users typed, which is why the scan does not need that material.