An AI launch needs a map of responsibilities before a compliance badge

A founder can demonstrate a working assistant in five minutes and still struggle to explain who is responsible for its behaviour. The model may come from one organisation, the application from another, and the decision to use its output from a customer. A policy review becomes useful when it follows

A founder can demonstrate a working assistant in five minutes and still struggle to explain who is responsible for its behaviour. The model may come from one organisation, the application from another, and the decision to use its output from a customer. A policy review becomes useful when it follows those relationships. A logo saying “responsible AI” cannot tell a procurement team which records exist, who can change the system, or which jurisdiction’s requirements were actually assessed.

Consider a fictional adult founder, Mira, preparing a multilingual document assistant for several markets. It summarises uploaded manuals and drafts answers for support staff. Her first useful document is a one-page description of intended use: who operates the service, which people receive answers, whether answers are advisory, and which actions remain outside the product. This is an editorial planning exercise using synthetic documents, not a report of a real launch or a legal conclusion about Mira’s business.

The same product description can lead to different legal questions

The European Commission’s current AI Act overview reports that the AI Omnibus entered into force on 27 July 2026. It gives 2 December 2027 for high-risk sensitive-area rules and 2 August 2028 for high-risk systems embedded in regulated products. These are distinct transitions, not evidence that every obligation waits until those dates. Specific provisions require the amended legal text and their own applicability assessment. [European Commission](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)

China’s 2023 Interim Measures concern covered generative services offered to the public within China. Article 2 excludes specified development and application activities that do not offer such public services; it does not exempt those activities from every other Chinese law. The measures took effect on 15 August 2023. Whether a service is public-facing is therefore a substantive scope question, not a choice of marketing language. [Cyberspace Administration of China](https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm)

NIST’s AI Risk Management Framework is intended for voluntary use. It offers a way to organise risk work across AI design, development, use and evaluation. That makes it useful vocabulary for an engineering discussion, but completing a framework worksheet does not establish that a product satisfies an applicable law. [US National Institute of Standards and Technology](https://www.nist.gov/itl/ai-risk-management-framework)

Singapore’s PDPC released the second edition of its Model AI Governance Framework on 21 January 2020. A model framework can help a team describe governance arrangements. Its existence should not be recast as a universal mandatory AI statute or a government approval for a particular application. [Personal Data Protection Commission Singapore](https://www.pdpc.gov.sg/help-and-resources/2020/01/second-edition-of-model-artificial-intelligence-governance-framework)

These developments illustrate why a launch map needs an instrument-type column. A binding measure, a legislative transition, a voluntary framework and a company promise have different authority. Mira can use similar evidence for several reviews, but she should not copy a conclusion from one column into another. Even apparently simple words such as “provider” may carry a defined meaning in one instrument and a commercial meaning in a contract.

Describe what each organisation can actually control

Mira’s team can draw four boundaries: model supply, application operation, customer configuration and the human decision. For each boundary it records the relevant organisation, the information it receives, the changes it can make and the evidence it supplies. The model vendor may explain model limitations without knowing how a customer uses a generated summary. The customer may understand its service obligations without seeing the application’s retrieval behaviour. The launch review must connect these pieces without pretending they are interchangeable.

A useful question is whether the assistant merely drafts a support response or also sends it. Sending introduces a new action boundary. A second question is whether the product remains an internal reference tool or is advertised for assessing people’s eligibility for services. The underlying model could be unchanged while the intended use, affected people and practical consequences change substantially. An engineering release process should therefore revisit the responsibility map when capabilities or customer claims change.

The team can test this with a deliberately awkward synthetic manual. It includes an outdated policy, an ambiguous diagram and a paragraph that contradicts another section. A reviewer records what the assistant retrieves, what it leaves uncertain and how an operator can inspect the source. The resulting record is evidence about that test configuration. It cannot establish performance in every language, every customer corpus or every legal setting, and should be labelled accordingly.

Make a launch packet that a second person can inspect

The packet should explain the product’s purpose in ordinary language, list its enabled capabilities and identify the version being reviewed. It should separate vendor descriptions from the team’s own observations. If a vendor says that data is not used for training, the packet records the relevant service terms and configuration rather than converting the statement into an independent technical audit. If a setting has not been verified, it remains an open item with an owner.

For Mira, a small change log is more useful than a broad declaration of trustworthiness. One entry might say that external sending remains disabled. Another might record a new translation feature and the languages actually evaluated. A third might identify an unanswered question about customer document retention. Each entry gives the next reviewer something concrete to inspect. None needs to claim that an entire jurisdiction has approved the product.

The packet also needs a recovery story. If the assistant cannot retrieve a reliable passage, the operator should see a clear explanation and a route to inspect the document or contact a responsible person. A raw model or database error would not help the operator assess the answer. Safe draft preservation matters: a failed response should not erase the question, upload context or human correction that the team needs to continue the task.

Ask questions that can change the release decision

An illustrative review can ask: Which organisation owns the user-facing explanation? Who can stop an unsafe capability? What evidence supports the advertised use? Which jurisdiction and instrument are being assessed? Which dates concern entry into force, application or enforcement? What happens if the customer changes the system’s purpose? These questions are valuable because different answers can change the proposed release, rather than merely improve the wording of a policy document.

A student studying this process can compare two fictional releases of the same assistant. In the first, it drafts answers for trained staff using public manuals. In the second, it ranks applicants using personal documents. The exercise is to identify the new decision boundary, affected people, data roles and evidence needs. The student should avoid declaring either release legally compliant from the scenario alone. The point is to learn how product facts determine the next questions.

The launch map remains a working document after release. Vendor updates, new destinations, changed customer claims and unexpected incidents can all make an earlier assessment incomplete. A practical team retains the reviewed version and records why a later version needs another look. As of 15 October 2026, the sources here support the specific developments described above; the proposed packet and examples are editorial tools for careful review, not legal certification or permission to launch.

Evidence diagram and readable guide


Original explanatory responsibility map for a fictional document assistant; not a legal determination, approval or observed deployment.

[Open the complete evidence diagram](/assets/policy-workflow-launch-responsibilities-20261016.svg)

Read the diagram

**An AI launch needs a map of responsibilities before a compliance badge**

A fictional launch review. Arrows connect responsibilities and evidence; they are not a legal approval or a chronological sequence for the four organisations.

- **Intended use** Describe the task, audience and actions the assistant can take.

- **Model supply** Ask what the supplier knows about model limits and service terms.

- **Application operation** Record enabled actions, retrieval behaviour and unverified settings.

- **Customer configuration** Identify the purpose and documents the customer chooses.

- **Human decision** Make review, correction and stopping responsibilities explicit.

- **Inspectable launch packet** Keep versioned evidence, open questions and a recovery route.

The four responsibility lanes are separate contributors. Evidence from one organisation does not settle another organisation’s duties.

How the connections work

- The intended use frames questions for the model supplier; a vendor description does not evaluate the complete service.

- The intended use identifies which application actions and settings need evidence.

- Customer purpose and configuration are examined against the intended use, not inferred from a model name.

- The review identifies which consequential decisions remain with people.

- Supplier information enters the packet with its source and limits, rather than becoming an independent audit.

- Observed application behaviour is retained with the configuration that was actually reviewed.

- Customer choices are recorded so a later purpose change can reopen the relevant questions.

- The packet names who can inspect, correct or stop the proposed action; it does not certify compliance.

Relationship key

Dashed arrows ask scope questions. Solid arrows contribute bounded evidence to the packet. Neither style means a regulator approved the launch.