.svg)
.svg)
Agentic AI Compliance in healthcare and finance
.png)
Most AI agents in healthcare and finance do not fail on accuracy. They fail the day someone from compliance asks a question the system cannot answer.
Who approved this payment? Which patient records did the agent read, and why? Can you replay the decision it made on 3 March?
Agentic AI compliance is the practice of designing, building and running AI agents so that every action they take is authorized, recorded, explainable and reversible under the rules of the industry they work in. In healthcare and finance that means HIPAA, GDPR, the EU AI Act, DORA and banking supervision can all apply at once, and almost none of them were written with agents in mind.
This guide covers which rules apply to AI agents in 2027, what reviewers ask for in each sector, the control layer every regulated agent needs, and how we deliver agents that pass review the first time. It builds on our general guide to getting an AI system through enterprise compliance review and goes deeper on the two sectors where the stakes are highest.
Why AI agents create new compliance risk in regulated industries
A model answers. An agent acts.
An AI agent plans a sequence of steps, calls tools, reads and writes data in other systems, and decides what to do next based on what it found. Each of those steps is a point where access, data handling and accountability have to be controlled, and where a reviewer will later want evidence.
That changes the compliance question. For a model, reviewers ask whether the output is correct and fair. For an agent, they also ask: was the agent allowed to take this step, with this data, on whose behalf, and can we prove it?
Regulators have started to say this out loud. In its 2026 oversight report, FINRA named six risks specific to AI agents, including autonomy and scope creep, agent actions that are hard to reconstruct afterwards, and sensitive data that agents keep or expose by accident. In April 2026 the Federal Reserve, OCC and FDIC replaced the long-standing SR 11-7 model risk guidance with SR 26-2, and stated in a footnote that generative and agentic AI are outside its scope. Banks are told to apply their own risk management to them.
In other words, there is no ready-made checklist for agents. The firm deploying the agent has to define the controls, and has to be able to show them.
Which regulations apply to AI agents in healthcare and finance in 2027?
No single law governs AI agents. In healthcare and finance, an agent inherits the obligations of the data it touches, the decisions it influences and the market it operates in. The table below lists the rules we see most often in projects for EU and US clients.
The biggest change in 2026 was the EU's Digital Omnibus, now in force. It moved the high-risk deadlines from August 2026 to 2 December 2027 for systems such as credit scoring, and to 2 August 2028 for AI built into regulated products such as medical devices.
Treat the extra time as build time, not waiting time. Enterprise buyers, auditors and supervisors already ask for logging, human oversight and documentation, and those are much cheaper to design in than to add after launch. Confirm the classification of your own system with legal counsel.
How to ensure compliance in healthcare-focused AI agent development
Short answer: treat every piece of patient data the agent can reach as a permission you have to justify, and keep a qualified person accountable for anything clinical.
Map every place patient data flows
Under HIPAA, every vendor that creates, receives, keeps or sends protected health information (PHI) for you needs a business associate agreement. For an agent, that list is longer than most teams expect: the EHR or practice system, the cloud provider, the model provider, the vector database, and the logging and observability tools that store prompts and responses.
Logs are the most common blind spot. If prompts contain PHI, so do your traces. In the EU, health data is special category data under GDPR, so you need an Article 9 condition, a DPIA, and a clear answer to where the data is processed and stored.
Apply "minimum necessary" to tools, not just to users
HIPAA's minimum necessary standard is easy to break with an agent that has one broad database tool. Give the agent narrow tools instead, such as "get the medication list for the patient in this case", scoped to the user and the record it is working on. The model then cannot reach data it was never meant to see, even if a prompt asks for it.
The same idea protects you from prompt injection: an instruction hidden in a referral letter cannot make the agent read records its tools do not expose. Our MCP security best practices guide covers how to scope tools this way.
Decide early whether the agent is a medical device
If the agent diagnoses, recommends treatment or drives clinical decisions, it may count as software as a medical device, which brings MDR in the EU, FDA oversight in the US, and the EU AI Act high-risk duties from August 2028.
Most agents we see in healthcare do administrative and regulated-content work: prior authorization paperwork, coding support, patient communication, scheduling and medical, legal and regulatory (MLR) review. Draw that boundary on purpose, write it into the agent's requirements, and test that the agent stays inside it.
Keep the clinician or reviewer as the approver
Human oversight only works if the review is fast and clear. Show the reviewer what the agent used, what it proposes and why, and make approving, editing or rejecting a single step. A review screen that takes longer than doing the task by hand gets skipped, and a skipped review is a compliance failure waiting to happen.
How to ensure AI agent compliance with banking and financial regulations
Short answer: put every agent in your model inventory, give it an authority limit the way you would give one to an employee, and make sure the system that does the work is not the system that checks it.
Inventory and classify every agent
SR 26-2 does not cover agents, but supervisors still expect you to know what you run. Record each agent with an owner, a purpose, the models and prompts it uses, the tools it can call and a risk tier. If an agent influences a credit decision about a person in the EU, it is likely high-risk under the AI Act from December 2027. In the US, lenders still have to give specific reasons when they turn down credit, however complex the system behind the decision.
Set authority limits and separate duties
Give agents explicit limits: payment amounts, account types, which records they can change. Above a limit, a person approves. An agent should never approve its own work, and the checks that validate an agent's output should run independently of the agent that produced it. This is the four-eyes principle, applied to software.
Treat model providers as ICT third parties
Under DORA, the cloud and model providers behind an agent belong in your register of ICT third-party providers, with contracts, exit strategies and incident reporting to match. Design for that from the start: keep the agent's logic and data in your own infrastructure, and make it possible to switch or fall back to another model without rebuilding the agent.
Make every decision reconstructable
FINRA's concern about long agent chains that are hard to reconstruct applies to banks, insurers and fintechs too. If a customer disputes a transaction or a supervisor asks about one decision, you need to replay what the agent saw, what it called, what it decided and who approved it. If you cannot replay a decision, you cannot defend it.
The 8 controls every regulated AI agent needs
The rules differ between healthcare and finance, but the controls that satisfy them are largely the same. We build these eight into every agent we deliver for a regulated client, before the first production release.
- An identity for the agent. The agent has its own service identity and acts on behalf of a named user, with that user's rights. No shared admin accounts, no keys copied between environments.
- Least-privilege tools. Narrow tools, scoped per user, role and tenant, and labelled as read-only or as actions that change data. Tools that change data or move money get extra checks.
- Data boundaries. Sensitive fields are masked or pseudonymized before they reach the model where possible. Data stays in the agreed region, and providers keep no prompts or outputs beyond what the contract allows.
- Human approval at material decisions. Approval points are defined by impact (a payment, a clinical message, a credit outcome), not only by the model's confidence. The reviewer sees the evidence, not just the answer.
- A complete, tamper-evident audit trail. For every run: the request, the data retrieved, each tool call and its parameters, the model and prompt versions, the output, the approver and the timestamps.
- Evaluation before every release. A test set built with your domain experts, including edge cases and known failure modes, with pass thresholds that the business owner signs off.
- Versioning and rollback. Prompts, models, tools and policies are versioned and released through development, staging and production, with a way to roll back in minutes.
- Monitoring and incident response. Alerts on unusual behavior, a way to pause an agent immediately, and a playbook that meets your reporting deadlines, from DORA incident reports to HIPAA breach notification.
None of these controls is exotic. What makes them hard is adding them late. An audit trail that was never captured cannot be rebuilt, and access that was granted broadly is painful to take back once workflows depend on it. That is why we treat them as part of the architecture, as described in what production-ready agentic AI really means.
How we deliver compliant agentic AI: ARC for regulated industries
ARC (Agentic Release Control) is Linnify's framework for building scalable, production-grade agentic infrastructure, combining software development discipline with human-led governance so companies keep full ownership of their AI systems.
In regulated work, its value is that every phase produces evidence a reviewer can use. Compliance is not a gate at the end. It is an output of each step.
- Assess. We score each use case for value and for risk and compliance exposure, and record which regulations apply and which risk tier it falls into.
- Ingest. With your domain experts we write the agent requirements: decision boundaries, data sources, approval points and escalation paths. This becomes the input for the DPIA and for the list of vendors that need a BAA or data processing agreement.
- Validate. We build a working prototype and measure it against a baseline your experts agree on, with guardrails and data lineage in place, before anyone talks about production.
- Deploy. The agent ships through a full release process with access control, logging and governance sign-offs. Legal, security and the data protection officer see the design in the first weeks, not at the final review.
- Optimize. Monitoring, anomaly detection and agent level agreements keep producing evidence after launch, so the next audit is a report, not a project.
Two principles matter most for healthcare and finance clients. First, the agent runs in your infrastructure and your data stays under your control, which makes data residency and third-party risk a configuration choice rather than a negotiation. Second, a named person is always accountable for what the agent does. Linnify is also ISO 27001 certified, so your security team can review our delivery controls against a standard it already knows.
For the wider picture of building, deploying and scaling agents, see our complete guide to AI agents for SaaS, and for why governance gaps have become a legal exposure, read enterprise AI governance is now a legal liability.
Agentic AI compliance: what to do next
Agentic AI compliance in healthcare and finance comes down to a simple standard: every action the agent takes should be permitted, visible and owned by a person. The regulations will keep moving, with the EU high-risk rules arriving in December 2027 and August 2028 and the US rules for agents still being written. The teams that build the control layer now will not need to rebuild when those rules land.
If you are planning an agent for patient data, claims, payments or credit, start by mapping which of the regulations above apply and which of the eight controls you already have.
References and further reading
• European Union. (2026). Digital Omnibus on AI: final text in force, summarized by Orrick, July 2026. orrick.com
• Gibson Dunn. (2026). EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes. gibsondunn.com
• European Parliament and Council. (2024). Regulation (EU) 2024/1689, the Artificial Intelligence Act. eur-lex.europa.eu
• Federal Reserve, OCC, FDIC. (2026, April 17). SR 26-2, revised model risk management guidance, summarized by Cutover. cutover.com
• FINRA. (2025, December). 2026 Annual Regulatory Oversight Report, summarized by Debevoise & Plimpton. debevoise.com
• Fierce Healthcare. (2026). Feds push back HIPAA security rule overhaul to July 2027. fiercehealthcare.com
• EBA, EIOPA and ESMA. (2026, July 31). Joint statement on governance and supervision of ICT risks from frontier AI. esma.europa.eu
• Linnify. (2026). How to get an AI system through enterprise compliance review. linnify.com
.png)
