Eighty percent of enterprise AI projects never reach production. The obstacle is rarely the model. It’s the absence of a control structure that regulators, auditors, and boards can actually examine.

An enterprise AI governance framework is the answer to that control structure problem. For regulated industries, the window to build one proactively is closing fast.

US federal and state regulators moved in 2023 and 2024. The Federal Reserve’s SR 11-7 model risk guidance now applies squarely to AI systems in banking. The NAIC issued its Model AI Bulletin in December 2023. The Colorado AI Act, New York DFS Circular Letter No. 7, and Texas TRAIGA each set specific obligations for AI use in high-stakes decisions. The EU AI Act is phasing into force for companies with EU operations. India’s DPDP Act, the UAE PDPL, Singapore’s PDPA, and Canada’s AIDA direction extend those expectations globally.

88% of enterprises use AI today. Only 39% report measurable financial results. The gap sits squarely in governance and process, not in the quality of the underlying models.

Data & AI capabilities at Scadea

What’s in this article

• What is an enterprise AI governance framework?
• Why does enterprise AI need governance now?
• What controls belong in an AI governance framework?
• How do AI governance frameworks map to regulations?
• Where does human-in-the-loop fit in the governance framework?
• How does AI governance scale to agentic systems?
• What does AI governance look like in regulated industries?
• What to do next
• Frequently Asked Questions

What is an enterprise AI governance framework?

An enterprise AI governance framework is a set of named controls, role assignments, and regulation mappings that span the full AI lifecycle from data sourcing through incident response.

An enterprise AI governance framework defines who owns each AI control, which regulation each control addresses, and what evidence auditors can inspect. It covers five lifecycle stages: data governance, model governance, deployment governance, monitoring governance, and incident response. Without this structure, AI programs accumulate untracked risk at each stage.

The word “framework” gets overused in AI governance writing. Here it means something specific: named controls with owners, mapped to named regulations, covering every stage where a model touches business decisions or personal data. Not a set of aspirational principles on a slide deck.

The 10/20/70 rule captures why this matters. Roughly 10% of AI program effort goes into the model itself, 20% into infrastructure, and 70% into the people, process, and governance work that determines whether the model actually runs safely in production. Most governance programs invert this ratio. They over-invest in model selection and under-invest in the control layer that keeps it auditable.

Why does enterprise AI need governance now?

Enterprise AI needs governance now because US federal banking regulators, state insurance commissioners, and state legislatures have issued specific, enforceable obligations, and enforcement timelines are active.

The NIST AI RMF 1.0, published in January 2023, and its 2024 Generative AI Profile gave US enterprises a structured risk vocabulary. Federal banking regulators followed. OCC Bulletins 2013-29 and 2023-17, combined with SR 11-7, require banks to apply model risk management discipline to AI systems used in credit, fraud, and AML decisions. HIPAA and HITECH apply to any AI system that processes protected health information, regardless of the model’s purpose.

At the state level, the pace accelerated through 2024. Colorado’s AI Act targets high-risk consequential decisions. New York DFS Circular Letter No. 7 and Part 500 set specific expectations for insurers and financial services firms using AI. Texas TRAIGA and Utah’s AI Policy Act extended similar frameworks. California’s CCPA/CPRA imposes data rights obligations on AI systems that process consumer data at scale.

For enterprises with EU exposure, the EU AI Act’s prohibited-use and high-risk-system provisions carry real operational weight, alongside GDPR’s existing automated-decision-making rules. DORA adds ICT third-party risk requirements for financial entities. India’s DPDP Act, UAE PDPL, UAE DIFC Data Protection Law, Singapore MAS FEAT criteria and PDPA, and Canada’s AIDA direction extend similar obligations to regions where US enterprises commonly operate.

Companies operating across 40 or more jurisdictions routinely discover that their AI programs weren’t built to satisfy any of these frameworks simultaneously. Building a governance framework retroactively, under regulatory pressure, costs significantly more than building one correctly during deployment.

NIST AI RMF EU AI Act Mapping: Enterprise Controls

What controls belong in an AI governance framework?

An AI governance framework needs 15 named controls grouped across five lifecycle categories: data governance, model governance, deployment governance, monitoring governance, and incident response.

The table below names each control and its primary governance purpose. This is a reference structure, not a compliance checklist. Specific obligations vary by jurisdiction, industry, and risk tier.

This 15-control structure is the operational backbone of an enterprise AI governance program. Each control needs an owner, a review cadence, and a way to produce evidence on demand.

How do AI governance frameworks map to regulations?

Each AI governance control maps to one or more named regulations, with US frameworks carrying the highest immediate compliance weight for most enterprises.

A few practical notes. NIST AI RMF is voluntary, but US agencies increasingly reference it in enforcement guidance, so treating it as a de facto baseline is sensible. Specific article or clause requirements vary by jurisdiction and are best confirmed with legal counsel. ISO/IEC 42001 is the most useful cross-jurisdictional anchor because its structure maps to both NIST and EU AI Act requirements.

Where does human-in-the-loop fit in the governance framework?

Human-in-the-loop (HITL) is a deployment-governance control, not a separate framework. It defines which decision types require human review before a model’s output triggers action.

Automation bias is the specific failure mode HITL addresses. It occurs when a human reviewer defers uncritically to the model’s recommendation, defeating the control’s purpose. Multiple US frameworks point to this risk. The NAIC Model AI Bulletin requires insurers to maintain human accountability for adverse underwriting decisions. FCRA adverse-action rules require accurate, human-verifiable explanations for credit denials. The Colorado AI Act sets HITL-adjacent disclosure and review requirements for consequential automated decisions.

EU AI Act high-risk system rules, India’s DPDP accountability obligations, Singapore’s MAS FEAT criteria, and Canada’s AIDA direction address automation bias in parallel ways across their respective jurisdictions.

Designing HITL correctly means specifying the decision types that need review, the minimum review criteria (what the reviewer must evaluate, not just acknowledge), escalation paths when the reviewer disagrees with the model, and audit log requirements that prove review actually occurred. A checkbox labeled “approved” with no documented rationale doesn’t satisfy SR 11-7’s independent validation expectations or the NAIC’s accountability requirements.

Human-in-the-loop at Scadea

Human-in-the-Loop AI Governance: Beyond Rubber Stamps

How does AI governance scale to agentic systems?

AI governance scales to agentic systems by extending four controls: agent-level permission scopes, action-by-action audit trails, explicit boundary definitions, and incident response procedures for autonomous failure modes.

Standard model governance assumes a human submits a query and a model returns a response. Agentic AI breaks that assumption. An agent can browse the web, write and execute code, send emails, call external APIs, and trigger downstream workflows, all without a human approving each step. The governance gap isn’t theoretical. An agent with access to a customer database and an email API can act at scale before any human notices a problem.

The four agentic governance controls extend the standard framework:

• Permission scopes: Each agent gets explicit, minimal access rights. Access is scoped to the task, not to the full data environment. This is the agentic equivalent of the principle of least privilege in ISO/IEC 27001.
• Action-by-action audit logs: Every external action an agent takes, not just the final output, is logged with a timestamp, triggering prompt, and the authorization chain that permitted the action.
• Boundary definitions: Specific action categories (financial transactions above a threshold, communications to external parties, schema modifications) require either HITL approval or are blocked outright.
• Incident response for autonomous failure: An agentic incident is not the same as a standard software bug. Response procedures cover agent suspension, action rollback where possible, affected-party notification, and audit trail preservation for regulatory review.

NIST AI RMF’s Generative AI Profile addresses some of these patterns. DORA’s ICT incident reporting requirements apply when an agentic failure meets the materiality threshold. State AI laws are still catching up to agentic architectures, but the underlying accountability principle is the same: the deploying organization bears responsibility for the agent’s actions.

Auditing Agentic AI: Boundaries, Logs, Incident Response

What does AI governance look like in regulated industries?

AI governance in regulated industries applies the same 15-control structure but weights different controls by sector, based on the specific regulatory obligations and failure modes each industry faces.

Banking, financial services, and insurance (BFSI). SR 11-7 and OCC 2013-29 make model inventory, independent validation, and ongoing monitoring the highest-priority controls. NAIC obligations add insurer-specific accountability requirements. Basel III and CCAR stress-testing rules apply when AI models feed risk calculations. FCRA and ECOA set explanation requirements for adverse decisions. A BFSI enterprise operating across 40 jurisdictions needs a compliance automation layer on top of the control framework, or manual tracking becomes the bottleneck.

Banking, financial services, and insurance at Scadea

Healthcare. HIPAA, HITECH, and 42 CFR Part 2 dominate. Any AI system that touches protected health information needs data access, data lineage, and breach-notification controls built into the deployment architecture, not added later. AI-enabled prior authorization tools need HITL controls that satisfy both HIPAA’s minimum-necessary principle and CMS program integrity requirements. One healthcare enterprise that automated prior authorization processing cut processing time from five days to 48 hours, but only after redesigning data access controls to meet HIPAA scope.

Gaming and hospitality. Title 31 BSA and FinCEN requirements apply to AI used in AML and suspicious-activity reporting. Responsible gambling AI tools face state-level gaming commission oversight. The NAIC Model AI Bulletin applies to any insurance product the gaming operator offers. Player analytics tools that influence marketing decisions also face FTC Section 5 scrutiny under the unfair or deceptive acts and practices standard.

Manufacturing. ISO/IEC 42001 and ISO/IEC 27001 are the most common anchors. AI systems in quality control, predictive maintenance, or supply chain optimization face fewer direct AI-specific regulations than BFSI or healthcare, but product liability exposure for AI-driven defects is an active legal risk. Model documentation and audit log controls are the most important starting points for manufacturing governance programs.

Industry-Specific AI Governance: BFSI, Healthcare, Gaming

What to do next

Start with a governance gap assessment. Map your current AI use cases against the 15-control framework above. Note which controls exist, which are partially in place, and which are absent. That gap map becomes the input to a prioritized build plan.

The most common finding: model inventory and use-case approval gates are missing entirely, while monitoring controls exist only for production-critical systems. HITL review is documented in policy but not enforced in process. Incident response procedures treat AI failures as standard software incidents rather than model-specific events.

Three concrete next steps:

1. Take the 10-category AI Readiness Assessment to score your governance program and get a gap diagnosis.
2. Download the Enterprise AI Governance Reference Framework whitepaper for a detailed implementation guide with control specifications and a regulation mapping appendix.
3. Book time with Scadea’s AI governance team to walk through the gap assessment results.

Frequently Asked Questions

What is the difference between an AI governance framework and AI ethics principles?

AI ethics principles are aspirational statements: fairness, transparency, accountability. An AI governance framework is operational. It’s named controls, role owners, regulation mappings, and audit evidence. Ethics principles may inform the framework’s design, but they’re not a substitute for it. A framework without operational controls isn’t a governance program.

Which US regulation requires AI governance most urgently for banks?

SR 11-7, issued by the Federal Reserve and the OCC, is the most directly enforceable framework for US banking organizations. It requires model inventory, independent validation, and ongoing performance monitoring for all models used in material business decisions. OCC Bulletin 2023-17 reinforced its application to AI and machine learning models specifically. Banks under SR 11-7 scope that haven’t applied it to AI models are exposed to supervisory criticism.

Does NIST AI RMF compliance satisfy EU AI Act requirements?

NIST AI RMF and the EU AI Act share structural similarities but aren’t interchangeable. NIST AI RMF is a voluntary risk management framework with no enforcement mechanism. The EU AI Act is binding regulation with conformity assessment requirements, incident reporting obligations, and prohibited-use provisions. An enterprise using NIST AI RMF as its governance base will have a head start on EU AI Act alignment, but specific EU Act obligations (registration, technical documentation, post-market monitoring) need additional work. ISO/IEC 42001 is the more direct cross-jurisdictional anchor.

What is human-in-the-loop (HITL) and when is it legally required?

Human-in-the-loop is a deployment governance control that requires a qualified human to review a model’s output before it triggers a consequential action. No single law universally mandates it, but multiple US regulations address related obligations. FCRA requires accurate, human-verifiable adverse-action notices for credit decisions. The Colorado AI Act requires disclosures and human review rights for high-risk consequential decisions. NAIC guidance requires insurer accountability for AI-driven underwriting decisions. The EU AI Act prohibits fully automated consequential decisions without human oversight for high-risk system categories.

How many AI controls does a typical enterprise governance program need?

A baseline enterprise AI governance program covers 15 controls across five lifecycle categories: data governance (3 controls), model governance (4 controls), deployment governance (3 controls), monitoring governance (3 controls), and incident response (2 controls). Not every control applies at equal weight across all use cases. Risk-tiering the model inventory lets governance teams focus the most intensive controls on the highest-stakes applications.

What is the NAIC Model AI Bulletin and who does it apply to?

The NAIC Model AI Bulletin, issued in December 2023, is guidance adopted by state insurance commissioners that sets expectations for insurers using AI in underwriting, claims, and rating decisions. It applies to licensed insurers and extends to third-party AI vendors used by those insurers. Key obligations include maintaining accountability for AI outcomes (even when the model is vendor-supplied), ensuring explainability for adverse decisions, and conducting ongoing monitoring. State adoption and enforcement vary; insurers should check the adoption status in each state where they operate.

How does AI governance apply to third-party AI vendors?

Third-party AI vendor governance is a named control in the deployment governance category. US frameworks are explicit: SR 11-7 applies model risk management requirements to vendor models used in material decisions. OCC 2013-29 extends third-party risk management to AI service providers. NAIC’s Model AI Bulletin holds the insurer accountable for vendor AI outcomes. DORA extends ICT third-party risk requirements to AI vendors used by EU financial entities. “The vendor is responsible” isn’t a defensible position with regulators. The deploying enterprise owns the risk.

What is ISO/IEC 42001 and how does it relate to AI governance?

ISO/IEC 42001:2023 is an international standard for AI management systems. It defines requirements for establishing, implementing, maintaining, and improving an AI management system within an organization. For enterprises operating across multiple jurisdictions, it serves as a cross-border governance anchor because its structure maps to both NIST AI RMF and EU AI Act requirements. Certification against ISO/IEC 42001 can simplify regulatory evidence packages in India, UAE, Singapore, and Canada, where regulators reference international standards in their guidance.

The post Enterprise AI Governance Framework: A Reference Structure for Regulated Enterprises appeared first on Data, AI, Automation & Enterprise App Delivery with a Quality-First Partner.

An insurance adjuster spends 25 minutes re-keying data from a scanned claim form. A bank’s onboarding team manually extracts fields from 14-page KYC packets. Neither problem is complex. Both are expensive, and both are solved by intelligent document processing.

Intelligent document processing (IDP) uses OCR, NLP, and machine learning to extract structured data from unstructured documents and route it directly into downstream systems like SAP, Salesforce, or ServiceNow. Best-in-class deployments reach 95%+ straight-through processing rates, meaning the system handles documents end-to-end with no human touch. One enterprise case study tracked order processing time dropping from 30 minutes to 5 minutes after IDP deployment.

This post covers how the IDP pipeline works, which platforms lead the market, and how the shift to LLM-based extraction changes the calculus for regulated industries.

What is intelligent document processing?

Intelligent document processing is the use of OCR, NLP, and machine learning to extract structured data from unstructured documents and route it to downstream systems automatically.

IDP handles the document types that kill manual workflows: invoices, contracts, insurance claims, loan applications, KYC packs, and compliance records. Unlike basic OCR, which converts image pixels to text, IDP understands context. It identifies that a string of digits is an IBAN, not a phone number. It classifies a page as a W-2, not a bank statement. It cross-checks extracted values against business rules before passing data downstream.

Grand View Research valued the IDP market at $2.3 billion in 2024, growing at a 33.1% CAGR through 2030. BFSI accounts for roughly 30% of all IDP spending. A 2025 SER Group survey found 65% of companies are accelerating IDP projects.

How does the IDP pipeline work?

The IDP pipeline is a five-stage architecture: pre-processing, classification, extraction, validation, and output. Each stage reduces error and increases the straight-through processing rate.

Pre-processing cleans raw inputs through binarization, de-skewing, noise reduction, and de-speckling before any OCR runs. Classification assigns each page a document type with a confidence score. Extraction pulls field-level data using OCR, ICR (Intelligent Character Recognition), and NLP models. Validation cross-checks extracted fields against databases using fuzzy logic, regex rules, and domain-specific business rules. Output delivers structured records into ERPs, CRMs, RPA bots, or AI pipelines downstream.

Validation is where regulated industries gain audit-readiness. Under SOX, HIPAA, GDPR, and AML/KYC requirements, every extracted field needs a traceable confidence score and a documented review path.

Which IDP platforms do enterprises use?

The leading IDP platforms for regulated enterprises are ABBYY Vantage, UiPath Document Understanding, Google Document AI, Azure AI Document Intelligence, Amazon Textract, and Tungsten Automation (formerly Kofax).

Platform selection usually comes down to deployment model and existing stack. Azure AI Document Intelligence fits naturally into hybrid and on-prem environments where data residency matters. Amazon Textract suits AWS-native pipelines. ABBYY Vantage leads on out-of-the-box document coverage with 200+ supported languages.

If you’re choosing a low-code platform to orchestrate these pipelines, see Appian vs. Mendix vs. Pega: Choosing a Low-Code Platform for Regulated Industries.

How do LLMs change document processing?

LLMs change IDP by handling free-form, unstructured documents that traditional OCR models can’t interpret reliably. But they introduce latency and cost tradeoffs that matter at enterprise scale.

Traditional OCR processes documents in milliseconds and costs fractions of a cent per page. LLMs like GPT-4 Vision, Claude 3.7 Sonnet, and Gemini 2.5 Pro take seconds per document and price on tokens. For a high-volume invoice processing pipeline, that cost difference compounds fast.

LLMs win on documents without fixed templates: free-form contracts, legacy records, handwritten notes. In testing on new insurance claim forms, an LLM achieved 97.2% extraction accuracy immediately, while a traditional ML model hit a 23% error rate after eight months of training.

The state-of-the-art approach in 2026 is hybrid: OCR for speed and structured fields, LLMs for reasoning and free-form content, with a mandatory validation layer. Without validation, unchecked LLM extraction pipelines carry a real hallucination risk.

What happens when the system isn’t confident?

When IDP confidence scores fall below a set threshold, the document routes to a human reviewer in a pattern called human-in-the-loop (HITL). Every correction the reviewer makes feeds back into the model.

Confidence scoring isn’t one-size-fits-all. Best practice is field-level thresholds. A customer name on a marketing form doesn’t need the same certainty as an IBAN on a payment instruction. Industry best practice sets confidence at 0.98 for payment-critical fields like IBANs and as low as 0.85 for line-item descriptions.

Standard tiers work like this. High confidence (90-100%) goes straight through. Medium (70-89%) gets flagged for exception review. Below 70% routes to a human. AWS supports this pattern through Amazon Bedrock Data Automation combined with Amazon SageMaker AI for multi-page document review.

The payoff is significant. HITL implementations reduce document processing costs by up to 70% and cut manual effort by up to 80% in production deployments. And the system improves over time. Every human correction raises the zero-touch rate without code changes.

To identify which document workflows are worth automating first, see Process Mining Before Automation: How to Find What’s Worth Automating.

What to do next

If your operations team still manually keys data from invoices, claims, or compliance documents, IDP is the most direct fix available. The technology is mature, the ROI is well-documented (30-200% in year one across published implementation case studies), and the platforms are production-ready for HIPAA, SOX, and GDPR environments.

Map your highest-volume document workflows against the IDP pipeline stages above to find where the biggest time losses sit.

Read next: Enterprise Hyperautomation: Combining Low-Code, AI, and Process Mining

The post Intelligent Document Processing: Extracting Structured Data from Unstructured Inputs appeared first on Data, AI, Automation & Enterprise App Delivery with a Quality-First Partner.