Most AI deployments we evaluate were approved by Legal in a single meeting where someone walked through a slide deck. The deck talked about "responsible AI." It used the word "guardrails." It mentioned that the vendor was SOC 2 certified. Legal asked a few questions, the team had reasonable answers, and the project moved forward.
A year later, the deployment is in production, the regulatory landscape has shifted, an incident has occurred, and Legal is being asked questions they cannot answer because the right ones were never asked at the start.
This is no longer acceptable. The EU AI Act's high-risk system obligations apply August 2, 2026. NIST AI RMF is now embedded in US federal procurement guidance and increasingly referenced in enterprise contracts. ISO/IEC 42001 certification is appearing on procurement due diligence questionnaires across regulated industries. The 2026 regulatory environment has converted AI governance from a voluntary best practice into operational infrastructure. Industry analysis indicates organizations with comprehensive AI governance frameworks reduce AI-related incidents by up to 70 percent and improve regulatory compliance by 55 percent compared to those with ad-hoc oversight.
There are five questions Legal, Compliance, and risk-aware executives should be asking before signing off on any AI deployment. They are not technical questions. They are governance posture questions, and the team building the deployment should be able to answer them in plain language. If they cannot, the deployment is not ready.
1. What is our regulatory exposure, and how have we addressed it?
Most AI initiatives proceed without a clear answer to which regulatory frameworks apply to the system being built. The team assumes "we're not in healthcare, so HIPAA doesn't apply" or "we're US-only, so GDPR doesn't apply" — and both assumptions are often wrong.
The honest version of this question has three parts. First: what regulatory frameworks could apply? HIPAA if any health-adjacent data touches the system. GDPR or CCPA if any user data is processed, regardless of where the company is headquartered. SOX if the system influences financial reporting. GLBA in financial services. FERPA in education. Industry-specific frameworks that may not be on Legal's standard list. The EU AI Act if the system is used in any way by EU customers, employees, or markets — and the extraterritorial reach is broader than most teams assume.
Second: of those that could apply, which actually do? This requires a systematic review, not a guess. Legal should expect to see documentation showing why each framework was evaluated and why it was either applied or excluded.
Third: for each framework that applies, what specific controls are in place to address it? "We have a security review process" is not an answer. "Our PII detection runs on every input and output, our audit logs are retained for seven years per SOX requirements, our data residency configuration restricts EU user data to EU regions per GDPR Article 44" — that is an answer.
When we run an Iron Pine Phase 1 Integration Assessment, the regulatory exposure mapping is a deliverable section in its own right. It covers every framework the system touches, the rationale for inclusion or exclusion, and the specific controls that address each one. Most teams have never produced this document for an existing AI deployment. The companies most likely to integrate AI at scale are the ones that produce it before they build, not after they get burned.
2. How does the AI handle PII, and can we prove it?
Almost every enterprise AI deployment touches personally identifiable information at some point. Customer names. Email addresses. Account numbers. Health information. Internal employee data. The question is not whether the system encounters PII — it is what the system does when it does, and whether the team can prove the system behaves the way they claim.
A defensible PII posture answers four sub-questions:
Detection. Does the system identify PII in inputs and outputs automatically, or does it rely on the user to know what they should not paste in? Automated detection using established libraries is now standard for enterprise deployments. Manual reliance is not.
Handling. When PII is detected, what happens? Is it redacted before reaching the model? Is the redacted version logged separately from the original? Is the original retained anywhere it should not be?
Audit. Can the team produce a complete record of every interaction the system had with PII for a given user, on demand? Audit logging that captures who asked what, when, what was returned, and what PII was involved is a baseline expectation for any system handling sensitive data.
Right-to-delete. When a user exercises their right to be forgotten, can the system actually forget them? This includes embedded vectors in the retrieval index, cached responses, audit logs (which may be exempt depending on the framework), and any downstream systems the AI fed.
The answers to these questions are not technical complexity. They are operating posture. A team that cannot answer them in straightforward language has not built a defensible system, regardless of what their security architecture looks like.
3. Who owns the AI in production, and what is the incident response plan?
The most overlooked governance question is also the most important when something goes wrong. Who owns this system after launch? Not "the team who built it" — that team will move on. Not "IT" — IT does not understand the model behavior. Not "the vendor" — the vendor cannot make business decisions about how to respond to a customer-impacting incident.
The right answer names a person, a backup, and a defined escalation path. It also names what specific incidents would trigger which response.
Five incident categories every team should have predefined responses for:
Model degradation. The model starts producing lower-quality answers. Who detects it, and how fast? Who decides to roll back to a prior version, and what does that involve technically?
Hallucination event. The system produces a confidently-worded wrong answer that reaches a customer or influences a business decision. Who is notified, what is the disclosure obligation, and what is the remediation path?
Cost spike. The system's API costs jump 10x in a week — usually due to a runaway loop, an abuse pattern, or a pricing change at the vendor. Who has authority to throttle or shut down? What is the kill switch, and who knows it exists?
Access anomaly. Someone accessed data through the AI they should not have been able to access. Who investigates, who notifies affected parties, and what is the regulatory disclosure path?
Vendor incident. The underlying model provider has an outage, a security incident, or a sudden policy change. What is the contingency, and is there a fallback model the system can route to?
A team that can describe these procedures crisply has thought about operating the system. A team that cannot has shipped infrastructure they do not know how to manage.
4. What is our governance framework alignment, and what do our deliverables prove?
Legal does not need the team to be ISO/IEC 42001 certified on day one. But Legal should expect the team to have explicitly chosen which governance frameworks the deployment aligns to and to be able to point to the deliverables that prove the alignment.
The three frameworks that matter for most US mid-market deployments in 2026:
NIST AI RMF. Voluntary, sector-agnostic, increasingly referenced in federal contracts and enterprise procurement. The four-function structure (Govern, Map, Measure, Manage) is the most flexible foundation and maps cleanly onto the other two frameworks. Most US-headquartered organizations should align here as their baseline, even if not formally certifying.
ISO/IEC 42001. The first international AI management system standard. Voluntary but certifiable. Increasingly listed in enterprise procurement due diligence. The right choice when third-party validation matters — typically for organizations selling into regulated industries or competing for enterprise contracts where governance maturity is a deciding factor.
EU AI Act. Binding law. High-risk system obligations apply August 2, 2026. The extraterritorial reach is broad: any organization with EU customers, EU operations, or EU employees may have systems that fall under the Act. The risk classification (prohibited / high-risk / limited-risk / minimal-risk) determines the obligation level.
The honest version of this question is not "are we aligned?" — it is "show me the documents that prove it." A control catalog listing each safeguard and how it is enforced. A compliance matrix mapping each control to specific framework clauses. A risk register identifying owners, mitigations, and evidence. These artifacts turn governance from an abstract concept into something an auditor can inspect.
If the team cannot produce these on request, governance is aspirational, not operational.
5. How will we know when the system stops behaving the way we claimed it would?
This is the question that distinguishes serious operators from everyone else.
Every AI deployment makes claims about how it behaves. It will not produce harmful outputs. It will not return data the user is not authorized to see. It will not cite sources that no longer exist. It will respond within a certain latency bound. It will not hallucinate beyond a certain rate. Each claim can be measured. Most are not.
Continuous evaluation is now the differentiator. The teams that have it know within a day when a model upgrade, a prompt change, a corpus update, or an underlying API change has degraded the system's behavior. The teams that do not have it learn from user complaints, by which point trust is already lost.
A defensible answer to this question describes:
Production observability. Every model interaction is logged with cost, latency, and a quality measure. Patterns are visible in real time. Anomalies trigger alerts.
Continuous evaluation. A curated test set runs against the system on a schedule — daily for high-stakes deployments, weekly for lower-stakes. Results are tracked as a time series. Regressions trigger review before they reach users.
Drift detection. The system flags when its inputs are starting to look meaningfully different from its training or evaluation distribution — an early signal that quality may be about to degrade.
Bias and fairness measurement. For systems that make or influence decisions affecting people, differential performance across demographics, regions, or use cases is measured and tracked.
The specifics depend on the deployment. The principle does not. A system in production without continuous quality measurement is a system you cannot defend. Legal asking this question, and getting a substantive answer, is the difference between a deployment that holds up under scrutiny and one that collapses the first time it is questioned.
What this means in practice
Legal teams have historically reviewed AI deployments the way they review software contracts — focused on liability allocation, data processing agreements, and IP ownership. Those questions still matter. They are no longer sufficient.
The 2026 regulatory environment has elevated AI governance to a question of operational architecture, not contract language. The questions above are not friendly suggestions. They are the questions a regulator, an auditor, or a plaintiff's attorney will ask if something goes wrong. Asking them at deployment time, when changes are still cheap to make, is the difference between defensible governance and a paperwork trail that documents the problem rather than preventing it.
When we engage with a client at Phase 1, the governance posture review is one of the deliverables. We map regulatory exposure, audit PII handling, document ownership and incident response, identify the appropriate framework alignment, and assess whether continuous evaluation infrastructure is in place. The output is a document Legal can use — not a slide that says "responsible AI" but a defensible record of how the system handles each of the five questions above.
That is the work. It is unglamorous. It is also what separates AI deployments that hold up under regulatory and legal scrutiny from the ones that quietly become liabilities the moment something goes wrong.
Iron Pine helps mid-market companies integrate AI into how they actually operate — grounded in your data, embedded in your workflows, adopted by your people, and operated with production discipline.
Talk to us about an Integration Assessment · Try the AI Health Check