Regulation guides for operating teams
EU AI Act: from obligations to service records
Provider and deployer roles, the amended timetable, transparency and human oversight.
Read the EU guide United States · Law and guidanceUS AI governance: scope the decision first
California, Colorado, Texas, FTC enforcement and the voluntary NIST AI RMF.
Read the US guideMedical AI: clinical responsibility and product requirements
Go deeper on FDA device boundaries, clinical decision support, quality systems, change control, health data, certified health IT and the EU medical-device overlap.
Read the medical AI guide →Scope the service before choosing a checklist
A customer support assistant, a clinical recommendation tool and an employment decision system raise different governance questions. A shared model should describe intended use, affected people, data sources, outputs and the people who can change a decision.
- Jurisdiction: where the organization operates, where people are affected and where the service or output is used.
- Role: who develops, supplies, deploys or materially changes the system. A vendor contract alone does not settle your legal role.
- Use case: whether AI drafts information, recommends an action or influences access to a service. Record the real human review process.
- Dependencies: what your team must obtain from vendors, implement in source systems and validate through operating evidence.
These are practical scoping questions, not a universal legal test. The guides below link the relevant rules to their own definitions and exceptions.
Use NIST AI RMF to organize the work
The NIST AI Risk Management Framework is voluntary guidance, not legislation or a product certification. Its four functions provide a useful structure for an ongoing governance process. NIST framework and status; NIST AI RMF Playbook.
| Governance concern | Operational practice | Liquid Learn capability | Limitation or dependency |
|---|---|---|---|
| Govern · Accountability | Assign service owners, review responsibilities and escalation decisions. | Owners on service steps and review records with reviewer details. | Your organization grants authority, resources and training. |
| Map · Context | Describe intended use, affected people, data and external dependencies. | Service flows, boundaries and data classifications. | Teams must validate scope and legal applicability. |
| Measure · Evidence | Choose evaluations and record their scope, results and limitations. | Evidence references in review packets and reviewed service snapshots. | Evaluations and performance measurements must be carried out separately. |
| Manage · Response | Decide what to change, who acts and when the service is reviewed again. | Controls in the service model, review comments and version context. | Implement and monitor the actions in the systems doing the work. |
A useful starting set of governance records
For each AI-enabled service, maintain an intended-use statement, a service map, accountable owners, an oversight and escalation procedure, a control list, evidence references and a dated review decision. Revisit the record when the model, data, provider, use case or affected population changes.
Separate three questions in every review: what the rule requires, what the team has done and what the evidence actually supports. A completed checklist or maturity score does not establish legal compliance.
Explore Liquid Learn’s AI governance software and the website and assessment security overview.
Connect the review to a real service
See how Liquid Learn connects AI service maps, accountable owners, controls and evidence. Or start with the 24-question health check for an immediate result and downloadable PDF roadmap.
Educational information, not legal advice. Applicability depends on jurisdiction, organizational role and use case. Confirm your obligations with qualified counsel. Liquid Learn supports governance work; using it does not certify or guarantee compliance.