For a lot of serious buyers the first question is not whether it is good. It is whether they can deploy it here at all. Enterprise, healthcare, and EU teams arrive with vendor reviews, data residency rules, and model restrictions that decide the architecture before a single feature does. The useful news is that the obligations are now written down in public, article by article, so you can build to them on purpose instead of discovering them at security review.
The mistake is to treat governance as a compliance layer you bolt on at the end. By then the shape of the system is set. Where data lives, what the model can see, what the product logged and what it threw away, these are architecture decisions, and the regulation names most of them for you. So read the specific duties, turn each into a thing the system does, and build it in while it is still cheap.
The constraints are the spec
Data residency, procurement review, allowed models, retention limits. Treat these as requirements from the first sprint, not surprises at security review. The EU's AI Act sets a risk based regime that is phasing in over several years, with the first prohibitions already in force and further obligations landing on a published schedule. Underneath it, the GDPR still governs the basics, purpose limitation and storage limitation, collect data for a stated reason and keep it no longer than you need. For anything touching health, the same logic runs through HIPAA. These rules shape where data flows, which models you can call, and what you can keep, and they are far cheaper to design in than to retrofit.
Risk based is the load-bearing phrase, and it is worth being precise about what it means. The Act sorts systems into tiers. A few practices are banned outright. A defined set of uses, the ones in Annex III (things like credit scoring, hiring, and access to essential services), are high risk and carry the heavy obligations. Most conversational products sit below that line but still pick up transparency duties. Knowing your tier is the first design decision, because it tells you which of the duties below actually bind you and how hard.
Read the Act by obligation, not by mood
The phrase risk based tells you the shape but not the work. The work is in the specific articles, and three of them decide most of what a conversational product has to build. Read them by number so you can point an engineer at the exact requirement.
Article 14 is human oversight. A high risk system has to be built so a person can understand it, monitor it, and step in or shut it down, with the design alert to the fact that people over-trust a confident machine. That is a product requirement, not a policy statement. The human sees enough to intervene and has a control that actually stops the run. It is the same discipline we cover in keeping the expert in the loop, read here as a legal duty rather than a quality one.
Article 50 is transparency. When a person is interacting with an AI system, they have to be told, unless it is obvious. AI generated or manipulated content, including deepfakes, has to be marked as such. For a chatbot this is small and concrete. Disclose that it is AI, and label synthetic media. It is also the one high risk deadline that did not move (more on that below), so it is the near-term one to ship.
The third duty is documentation. High risk systems carry technical documentation, logging, and a record of how the system was built and tested, so a regulator or a buyer can reconstruct what happened. This is where an audit trail stops being nice to have. If the product cannot produce the record on request, the record does not exist. Refusal and escalation logic belongs in the same frame, because a system that knows when to refuse and escalate is easier to document and defend than one that improvises.
Build the guardrails in
Data handling, retention, refusal, escalation, and auditability belong in the system itself. The US reference for this is NIST's AI Risk Management Framework, built around four functions, govern, map, measure, and manage, that front load exactly the privacy and accountability questions a buyer will ask. Its Generative AI Profile names data privacy and information security as first class risks and lists concrete actions for each.
Read the four functions as the order a buyer's security team runs their questions in. Govern is the org level. Who owns this system, what is the policy, who signs off. Map is scope. What is this thing, whose data does it touch, what could go wrong in context. Measure is evidence. How do you know it works and stays working, which is the eval question, the same loop as what you can keep when you decide what to store and prove. Manage is response. What happens when it fails, who gets told, how does it get fixed. A product with an answer at each stage passes the review, because the review is those four questions.
A governed product can show what it did, why, and on whose data, because that record was designed in from the start, not reconstructed under pressure.
Certification is becoming table stakes
Buyers increasingly want a credential they can check, not a promise. ISO/IEC 42001, published at the end of 2023, is the first certifiable management system standard for AI, and procurement teams now ask for it by name. A management system standard does not certify the model. It certifies that the organization has a repeatable process for governing AI, and it runs on the same Plan-Do-Check-Act loop as ISO 27001 for security or 9001 for quality. Plan the controls, do the work, check that it held, act on what you found, and keep the cycle turning. That structure is why an auditor can score it and why a buyer treats the certificate as evidence rather than a slogan.
The frontier labs already treat these artifacts as the cost of doing business. OpenAI publishes a no train default for business data and a 30 day default retention window, and Anthropic's Trust Center lists SOC 2, ISO 27001, ISO 42001, and HIPAA support through a signed agreement. If the companies selling the models design for this from the start, a product built on top of them has no excuse not to. Often the certificate a buyer wants from you is one the model vendor already holds, so you inherit part of the posture and owe the rest at your own layer.
Build for the regulation that arrived
The obligations are real, and this year the dates finally settled. On 7 May 2026 the Council and Parliament reached a provisional agreement on a Digital Omnibus (the AI Act simplification package, part of the EU's Omnibus VII), the first substantive change to the Act since it passed in 2024. Parliament endorsed it on 16 June, and on 29 June the Council gave its final green light, so as of this writing (July 2026) it is adopted and awaiting publication in the Official Journal before it enters into force. This is no longer a proposal to track. It is law with a known shape.
What it did was push the high risk obligations under Annex III out. Standalone Annex III systems move from 2 August 2026 to 2 December 2027, and high risk AI embedded in regulated products moves to 2 August 2028. The stated reason is plain. The standards and support infrastructure to make those duties operable were not ready, so the deadline moved to meet reality. The Omnibus also trims some of the documentation load.
One date did not move, and it is the near-term one. The Article 50 transparency duties still apply from 2 August 2026, unchanged by the Omnibus. So the chatbot disclosure and the deepfake labeling are the obligations to ship this summer, while the heavier Annex III machinery bought about sixteen to twenty extra months. Track the official timeline rather than any one summary, because the dates are the part most likely to shift again.
The schedule eased. The direction did not. Transparency, human oversight, and documentation are still where this lands, and the labs and the US framework point the same way. A slipped deadline is a reprieve, not a reason to wait, and this reprieve came with the near-term transparency clock still running.
The takeaway
Governed environments reward the team that reads the obligations by name and builds each one in while it is cheap. Name your risk tier. Ship the Article 50 disclosure now, because that date held. Build the Article 14 oversight control and the documentation trail into the architecture, not onto it. Run the NIST four functions as the questions the buyer will ask. Retention and deletion are their own surface, so decide early what you can keep and treat memory as the trust surface it is. Do this from the first sprint and the vendor review stops being a wall and becomes a form you have already filled out.
Sources and further reading
Work with Hunter Green