The Big Idea
A May 2025 tertiary review by Ribeiro, Rocha, Pinto, Cartaxo, Amaral, Davila, and Camargo synthesized nine peer-reviewed secondary studies on AI governance published between 2020 and 2024, and its central finding is one most practitioners already sense: the EU AI Act and NIST AI Risk Management Framework dominate the literature as the reference frameworks, transparency and accountability emerge as the most frequently cited principles, and yet the research community has produced almost no work on how to actually implement either. The gap the paper identifies is not in principles - every survey produces the same list - but in actionable mechanisms: the concrete decisions, artifacts, and checkpoints that translate a governance statement into a deployable system. This article bridges that gap from the practitioner side. It maps the EU AI Act's risk tiers and the NIST RMF's four-function cycle onto the specific decisions you face when building AI-powered automations, and shows what governance looks like when it is embedded in the workflow rather than appended as a policy document.
Before vs After
Ungoverned AI Deployment
- Model chosen based on benchmark leaderboard position, no risk classification step
- Training data sourced without documentation of provenance or consent scope
- No version pinning - model updates silently change output behavior in production
- Output monitoring limited to error rates; no fairness or calibration checks
- No human review checkpoint for high-stakes outputs (credit, hiring, medical triage)
- Compliance addressed post-deployment as a legal review, not a build-time constraint
- Incident response is ad-hoc - no defined process for bias reports or model failures
Governed AI Deployment
- Risk tier assigned at design time using EU AI Act classification criteria
- Data lineage documented in a model card before any training run begins
- Model version pinned in deployment config; update requires explicit re-evaluation gate
- Monitoring pipeline checks output distribution drift, demographic parity, and calibration weekly
- High-risk use cases enforce a human-in-the-loop review step before action is taken
- Compliance checklist integrated into CI/CD pipeline - deployment blocked if checklist fails
- Incident response playbook defined with escalation paths and rollback procedures
How It Works
Step 1 - Classify Your System Under the EU AI Act Risk Tiers
The EU AI Act organizes AI systems into four risk tiers, and the tier determines the compliance obligations that apply. Unacceptable risk covers systems that are prohibited outright: social scoring by public authorities, real-time biometric identification in public spaces (with narrow law enforcement exceptions), and AI that manipulates users through subliminal techniques. High risk covers systems deployed in eight regulated domains - education and vocational training, employment and worker management, essential services (credit, insurance), law enforcement, migration and border control, justice, critical infrastructure, and medical devices - and imposes the heaviest obligations: conformity assessment, technical documentation, human oversight, accuracy and robustness requirements, and registration in an EU database. Limited risk applies to systems with transparency obligations only, meaning users must be informed they are interacting with AI. Minimal risk covers everything else, with no mandatory requirements beyond the voluntary codes of practice. For most practitioners building internal automation tools, document processing pipelines, or customer-facing assistants, the classification falls in limited or minimal risk - but the classification exercise itself surfaces assumptions that need to be examined before deployment.
| Tier | Examples | Key Obligations |
|---|---|---|
| Unacceptable | Social scoring, real-time biometric ID, subliminal manipulation | Prohibited - cannot deploy |
| High Risk | CV screening tools, credit scoring, medical device AI, law enforcement | Conformity assessment, technical documentation, human oversight, EU database registration |
| Limited Risk | Chatbots, deepfake generation, AI-generated content | Transparency disclosure to users - must inform that AI is involved |
| Minimal Risk | Spam filters, recommendation engines, document summarization | No mandatory requirements; voluntary code of practice |
Step 2 - Run the NIST RMF Cycle Before You Deploy
The NIST AI Risk Management Framework (NIST AI RMF 1.0, published January 2023) organizes AI governance into four functions: GOVERN, MAP, MEASURE, and MANAGE. These are not sequential phases - they run as a continuous cycle across the AI system lifecycle. GOVERN establishes the organizational policies, roles, and accountability structures that make the other three functions work: who is responsible for risk decisions, what escalation paths exist, and what the risk tolerance threshold is for the specific deployment context. MAP identifies and categorizes the risks that apply to your system given its use case, stakeholder population, and deployment environment - including harms that are not immediately obvious from a technical review. MEASURE applies quantitative and qualitative evaluation methods to assess the severity and likelihood of the mapped risks: bias audits, red-teaming, calibration testing, and third-party audits. MANAGE implements the controls, monitoring, and incident response processes that maintain acceptable risk levels in production. The practical value of the cycle is that it forces documentation at each step, which is itself the primary gap the Ribeiro et al. review identifies: governance without documentation is indistinguishable from no governance.
Step 3 - Embed Governance Artifacts Into the Build Process
Governance frameworks produce value only when their required artifacts are produced and maintained as part of normal engineering work, not assembled retrospectively for audits. There are four artifacts that cover the requirements of both the EU AI Act and the NIST RMF for most practitioner deployments. The first is a risk classification record: a one-page document that states the EU AI Act tier, the NIST RMF risk categories that apply, and the rationale for each classification. This exists to surface assumptions - if you cannot write two sentences justifying your tier assignment, the classification is not complete. The second is a model card: a structured description of the model's intended use, training data, known limitations, evaluation results, and out-of-scope uses. Model cards are the accountability artifact that connects a specific model version to its documented claims. The third is a monitoring specification: a written definition of which output metrics will be tracked in production (accuracy, demographic parity, calibration error, output distribution), at what frequency, and what thresholds trigger review. The fourth is an incident response playbook: a defined sequence of steps for detecting, investigating, and remediating a governance failure - including rollback procedures and communication responsibilities.
Step 4 - Define the Human-in-the-Loop Threshold
The most practically underspecified requirement in both the EU AI Act and the NIST RMF is human oversight. Both frameworks require it for high-risk systems, and neither specifies what it means operationally. There are three distinct patterns. Full human review requires a human to review and approve each AI output before any action is taken - appropriate for consequential individual decisions like credit denials or employment rejections, where EU AI Act Article 14 requires the ability to meaningfully override the AI. Sampling-based review routes a configurable percentage of outputs to human review, selected either randomly or by confidence threshold - appropriate for high-volume, moderate-stakes workflows where full review is operationally infeasible. Anomaly-triggered review runs all outputs through automated checks and routes only those that fall outside defined distribution bounds or confidence thresholds to human review - appropriate for document processing, summarization, and classification at scale. The choice of pattern is a risk decision, not an engineering one: it follows from the MAP stage of the NIST RMF cycle and the EU AI Act tier classification, and it needs to be documented as a governance artifact before the system ships.
Key Findings
- EU AI Act risk tier classification is the correct entry point for any governance process. The tier determines mandatory obligations and the appropriate level of documentation investment. Organizations that skip this step and go straight to implementing transparency measures often over-invest in low-risk systems and under-invest in high-risk ones.
- The NIST RMF cycle is continuous, not sequential. GOVERN and MAP must be revisited every time the use case, the model version, or the deployment population changes. A governance artifact that was accurate at deployment becomes a liability if it is never updated.
- Documentation is the primary missing mechanism identified in the literature. The Ribeiro et al. review found that the research community has produced extensive lists of principles but almost no work on the specific artifacts, templates, or checklists that make those principles auditable. Model cards, risk registers, and monitoring specifications fill that gap directly.
- Transparency and accountability are operationally distinct requirements. Transparency means users and stakeholders have access to information about how a system works and what it can and cannot do. Accountability means specific humans or organizations are answerable for specific outcomes. Both are cited as top principles in the literature, and both require different artifacts: transparency requires model cards and disclosure notices, accountability requires ownership records and escalation paths.
- The gap between principles and practice is a process design problem, not a technology problem. The EU AI Act and NIST RMF provide sufficient structure for most deployments. What organizations lack is the engineering process that makes governance artifacts a build-time requirement rather than a post-deployment checklist.
Why This Matters for AI and Automation Practitioners
The EU AI Act entered into force in August 2024 and begins phased enforcement through 2026 and 2027, with provisions for high-risk systems and general-purpose AI models applying progressively. Practitioners building automation systems that touch employment screening, credit decisions, access to essential services, or any of the other eight high-risk domains face real compliance obligations with real enforcement risk - not hypothetical governance requirements. The NIST RMF is voluntary in the US context but increasingly referenced in federal procurement requirements and sector-specific regulation. More practically, the research context from Week 21 (Papagiannidis, Mikalef, and Conboy) demonstrates that organizations that move from principles to structural and procedural governance practices - the ones that actually define roles, document processes, and monitor outcomes - produce AI systems that generate measurably more trust with stakeholders and face fewer post-deployment remediation costs. Governance embedded at build time is cheaper by orders of magnitude than governance retrofitted after a regulatory finding or a public incident.
My Take
The Ribeiro et al. tertiary review is a useful signal precisely because of what it does not find. Synthesizing nine secondary studies covering dozens of primary papers, it cannot point to a single body of work that tells practitioners how to implement the principles it summarizes. That is not a criticism of the researchers - it reflects a genuine gap in what the field has produced. The EU AI Act fills part of that gap for European deployments by converting principles into legal requirements with defined artifact obligations. The NIST RMF fills another part by providing a structured cycle for risk management. What neither provides is a mapping from those frameworks to the specific engineering decisions that practitioners face when deploying an LLM-based automation, a classifier in a hiring workflow, or a recommendation engine in a financial product. That mapping is still built by practitioners one project at a time, and sharing it in concrete form - as a pipeline diagram, a CI/CD gate spec, a model card template - is more useful than another survey of principles. The honest limitation of the governance approach described here is that it adds overhead. A risk classification record and a model card take time to produce and maintain. For minimal-risk internal tools, that overhead may not be justified. For anything touching a high-risk domain or a population that cannot easily contest an automated decision, it is not optional.
Discussion Question
The EU AI Act places the compliance burden on the deployer, not just the model developer - meaning an organization using a third-party LLM in a high-risk application is responsible for conformity assessment, human oversight, and technical documentation even if it did not train the model. In practice, most practitioners using API-based models have limited visibility into training data, evaluation methodology, and model behavior under distribution shift. How should a practitioner meet the EU AI Act's documentation and human oversight requirements for a high-risk system when the underlying model is a black box supplied by a third-party provider?