> ## Documentation Index > Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt > Use this file to discover all available pages before exploring further. # Regulation mapping > How Parmana supports human oversight and record keeping under the EU AI Act (Articles 12, 14 and 26), the NIST AI RMF, ISO/IEC 42001 and RBI guidance for Indian banks and NBFCs: what it provides, the evidence, and what stays with your organization. Compliance teams ask how an AI agent is overseen and how its actions are recorded. This page maps Parmana to the provisions they cite: the EU AI Act's human oversight and record keeping articles, the NIST AI Risk Management Framework, ISO/IEC 42001, and the Reserve Bank of India's IT and AI guidance. **What Parmana is, for these purposes.** Parmana is not itself an AI system. It sits between an AI agent and the systems it acts on, refuses any action a person has not approved, and signs a record of each action and each refusal. It is a technical measure a provider or deployer of an AI system can use to meet oversight and logging obligations for the actions an agent takes. It does not make a system compliant on its own, it does not cover the model, and this page is not legal advice. Ratings, as on the [OWASP mapping](/security/owasp-mapping): * **Supports:** Parmana provides a technical measure that meets the requirement for actions that go through it, with evidence you can check. * **Partly:** Parmana provides part of it. The rest is named. * **Organizational:** the requirement is about people, training or process. Parmana can record it, not do it. Evidence refers to sections of [docs/CLAIMS.md](https://github.com/pavancharak/parmana/blob/main/docs/CLAIMS.md), threats in [THREAT-MODEL.md](https://github.com/pavancharak/parmana/blob/main/THREAT-MODEL.md), and attack scenarios you can run with `npm run evaluate -- EV-xx` ([Evaluate Parmana](/evaluation/overview)). ## EU AI Act Articles 12, 14 and 26 apply to high-risk AI systems. Under the Digital Omnibus on AI, in force since July 2026, the high-risk obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Check the current text and your system's classification with counsel. | Provision | What it asks | Rating | What Parmana provides | Evidence | What stays with you | | - | - | - | - | - | - | | Art. 14(1) | The system can be effectively overseen by natural persons while it is used, including through suitable tools. | Supports | A person is placed before every action: no agent action runs without a signed approval from a registered approver for that action and resource, and the amount where the policy names one. Reads included. | 2.42, 2.47; T2; EV-04 | Designing the agent and its use so that the actions that matter go through Parmana. | | Art. 14(4)(a) | Overseers can monitor operation and detect anomalies. | Partly | Every action and every refusal has a signed record a person can read and verify offline; callers' requests are in a hash chained audit trail. Approvers can be told when a request waits on them. | 2.5, 2.6, 2.46; T12; EV-14 | Understanding the model's capacities and limits; dashboards and alerting on the records. | | Art. 14(4)(b) | Overseers stay aware of automation bias. | Organizational | The approver signs one specific action, resource and amount, not a standing permission. | 2.42 | Training approvers. | | Art. 14(4)(c) | Overseers can correctly interpret the output. | Partly | What an approver signs names the action, the resource and the amount in plain values, so the approver sees what will happen, not the model's reasoning. | 2.42 | Explaining the model's output. | | Art. 14(4)(d) | Overseers can decide not to use, disregard or override the output. | Supports | An action the agent proposes does not run unless a person signs for it; not signing is a refusal, recorded and signed. | 2.47; T2; EV-04 | Reversing an action that already ran is a business process in the target system. | | Art. 14(4)(e) | Overseers can intervene or stop the system. | Partly | Remove an agent's key to stop it acting (effective on restart or redeploy); revoke an approver or an external connector through maker checker; approve a policy version that refuses. An approval already signed expires within its lifetime. | 2.16, 2.45, 2.49; T1, T11 | Stopping the agent itself; an action already released is not recalled. | | Art. 12 | The system automatically records events (logs) over its lifetime, to identify risks and monitor operation. | Supports | Each approved action has a signed Execution Trust Record (the decision, the policy and its version, the approval, the authorization, the result), each refusal a signed Refusal Record, and each caller request a chained audit event. Records verify offline with only the public key. | 2.5, 2.6, 2.19; T12, T14; EV-14 | Logging inside the model and the agent. | | Art. 26(1), (2) | Deployers use the system as instructed and assign oversight to people with the necessary competence, training and authority. | Partly | Approvers are registered keys, added and revoked through maker checker, so who may approve is explicit and recorded. | 2.45; T11 | Choosing and training approvers. Approvers are not yet limited to particular actions or policies (G-50). | | Art. 26(6) | Deployers keep the system's logs for at least six months. | Partly | Records are stored in the deployer's own database; no repository has a delete method, and a deleted row breaks the hash chain. | Limitations: audit tampering | Setting and enforcing retention, and backups. | ## NIST AI Risk Management Framework (AI RMF 1.0) | Subcategory | What it asks | Rating | What Parmana provides | Evidence | What stays with you | | - | - | - | - | - | - | | GOVERN 3.2 | Roles and responsibilities for human-AI configurations and oversight are defined. | Partly | The roles are enforced in software: an agent can propose, only a registered approver can approve, and policy and approver changes need a second person. | 2.26, 2.45, 2.47; T11; EV-13 | Defining the roles in your organization; per action approver limits (G-50). | | MAP 3.5 | Processes for human oversight are defined, assessed and documented. | Supports | Each action's policy states, in a versioned file approved through maker checker, which approval it needs; the record shows the approval used. | 2.26, 2.42, 2.47 | Documenting why each oversight level was chosen. | | MANAGE 2.4 | Mechanisms exist to supersede, disengage or deactivate an AI system whose outcomes are inconsistent with intended use. | Partly | Actions can be stopped by removing the agent's key, approving a refusing policy version, or revoking a connector or approver. | 2.16, 2.45, 2.49 | Stopping the model or agent itself. | | MEASURE 2.7 | Security and resilience are evaluated and documented. | Supports | A threat model, 16 runnable attack scenarios, a public security challenge, mutation and fuzz tests. | THREAT-MODEL.md; `npm run evaluate`; docs/MUTATION-TESTING.md | Evaluating the model and your deployment. | | MEASURE 2.8 | Transparency and accountability risks are examined and documented. | Supports | Each action is attributable: the record names the caller, the approver, the policy version and the result, signed. Claims and open gaps are published. | 2.5, 2.6; CLAIMS.md, VERIFICATION-GAPS.md | Accountability for decisions made outside Parmana. | | MANAGE 4.1 | Post-deployment monitoring, including override, incident response and change management. | Partly | Refusals are recorded and signed; policy changes go through maker checker with a signed approval record; records can be replayed and verified. | 2.26, 2.7 | Monitoring and incident response processes. | ## ISO/IEC 42001 (AI management system), Annex A | Control | What it asks | Rating | What Parmana provides | Evidence | What stays with you | | - | - | - | - | - | - | | A.3.2 AI roles and responsibilities | Define and allocate responsibilities for AI activities. | Partly | Approver and maker checker roles are enforced and recorded. | 2.26, 2.45 | The allocation itself; G-50. | | A.6.2.6 AI system operation and monitoring | Operate and monitor the AI system. | Partly | Every action is checked against its policy and approval before it runs, and recorded after. | 2.47, 2.5 | Monitoring the model's performance. | | A.6.2.8 AI system recording of event logs | Record event logs across the life cycle. | Supports | Signed Execution Trust Records, Refusal Records and a chained caller audit trail, verifiable offline. | 2.5, 2.6, 2.19; EV-14 | Retention, and logs inside the model. | | A.9 Use of AI systems | Use AI systems responsibly and as intended. | Partly | Each agent's key is limited to the actions it is meant to take, each action to its policy, each policy to an approval. | 2.16, 2.22, 3.16; EV-12 | Defining intended use. | | A.10 Third-party and customer relationships | Manage AI related risks with suppliers and customers. | Partly | External systems are reached only through connectors registered by maker checker, with signed releases. | 2.49, 2.50 | Supplier agreements and assessment. | ## Reserve Bank of India (RBI) For banks, NBFCs and payment system operators using AI agents, for example an agent that issues refunds through the Paytm connector ([Connectors](/handbook/12-connectors)). Three RBI texts are relevant, with different status: * The **Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices** (7 November 2023, in force from 1 April 2024) is binding on the banks, NBFCs, credit information companies and all India financial institutions it names. * The **FREE-AI Committee report** (Framework for Responsible and Ethical Enablement of AI, 13 August 2025) makes 26 recommendations. It is a committee report, not a direction. * The **draft Guidance on Regulatory Principles for Model Risk Management, 2026** (24 June 2026, consultation closed 24 July 2026) covers AI and machine learning models. It is a draft; check the final text. Provisions are summarized, not quoted, and FREE-AI recommendations are given a number only where it was confirmed. Read the source texts. | Provision | What it asks | Rating | What Parmana provides | Evidence | What stays with you | | - | - | - | - | - | - | | IT Direction, audit trails | Applications that can access or affect critical or sensitive information have audit and system logging and provide audit trails; logs are monitored to detect unauthorised activity. | Supports | Each approved action has a signed Execution Trust Record, each refusal a signed Refusal Record, each caller request a chained audit event; a refused write to the audit trail refuses the request. | 2.5, 2.6, 2.19, 2.32; T12; EV-14 | Monitoring the records; retention; logs of systems that do not go through Parmana. | | IT Direction, cryptographic controls | Key lengths, algorithms, cipher suites and protocols used for data and authentication are strong. | Supports | Records and approvals are signed with Ed25519, optionally together with ML-DSA-65 (post quantum); each key is bound to its algorithm. | 2.13, 2.14, 3.13 | TLS configuration; key storage and rotation in your key management system. | | FREE-AI, board approved AI policy | The board approves an AI policy covering governance, the AI lifecycle, risk controls and vendor liability. | Organizational | Each action's policy is a versioned file approved through maker checker, so the policy in force for every action is recorded. | 2.26, 2.34 | The board policy itself. | | FREE-AI Rec. 21, business continuity for AI systems | Fallbacks such as human in the loop review, and periodic tests of the fallback. | Partly | Parmana fails closed: when the policy, the approval or the signing key is missing or invalid, the action is refused, not run without checks. A human approval can be required for any action. | 2.12, 2.17, 2.47; T2 | The manual process that takes over when the agent is stopped, and testing it. | | FREE-AI Rec. 22, AI incident reporting | Report AI incidents to a sector framework in time. | Partly | Signed records of what the agent did and what was refused, verifiable by a third party, to support an incident report. | 3.11; EV-14 | Detecting incidents and reporting them. | | FREE-AI Rec. 24, AI audit framework | AI systems are audited, internally and by third parties. | Supports | An auditor can verify every record offline with only the public key, without access to your systems. Claims, tests and open gaps are published. | 2.5, 3.11; CLAIMS.md | Running the audit; auditing the model. | | FREE-AI Rec. 25, disclosures | Disclose AI governance, adoption and consumer protection, for example in the annual report. | Organizational | Records can show how many actions were approved and refused, and by which policy. | 2.5 | The disclosure. | | Draft MRM guidance, kill switch | A malfunctioning AI model can be suspended or deactivated at once. | Partly | An agent's actions can be stopped: approve a policy version that refuses, revoke a connector or an approver, or remove the agent's key (effective on restart or redeploy). An action already released is not recalled. | 2.16, 2.45, 2.49; T1, T11 | Stopping the model or agent itself. | | Draft MRM guidance, documented human oversight | Human oversight of model use is documented, with periodic human review of outputs. | Supports | No agent action runs without a signed approval from a registered approver; the record names the approver, the policy version and the result. | 2.42, 2.47; T2; EV-04 | Periodic review of the model's outputs that do not become actions. | | Draft MRM guidance, model inventory and named roles | Every model is in an approved inventory with a named owner, developer, validator and approver. | Organizational | Approvers are registered keys added and revoked through maker checker, so the people who approve agent actions are named and recorded. | 2.45; T11 | The model inventory. Approvers are not yet limited to particular actions or policies (G-50). | | Draft MRM guidance, customer disclosure | Customers are told when they deal with AI and can switch to a human. | Organizational | Nothing directly. | | The disclosure and the hand over to a person. | ## Reading this page * **Only actions that go through Parmana are covered.** Give agents credentials only to Parmana, so it is the one route to your systems. * **Each rating has evidence you can check:** run the attack scenarios, read the claim and its tests. * **Open issues that matter here:** approvers are not yet limited to particular actions or policies (G-50); facts an agent declares are not checked against another system and can only refuse (G-51). See [Limitations](/security/limitations#open-issues). * **This is a mapping, not a certification or legal opinion.** The provisions are summarized; read the source texts: [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), [NIST AI RMF 1.0](https://www.nist.gov/itl/ai-risk-management-framework) and [ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html), the [RBI IT Governance Master Direction](https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12562) and the [FREE-AI report](https://rbidocs.rbi.org.in/rdocs/PublicationReport/Pdfs/FREEAIR130820250A24FF2D4578453F824C72ED9F5D5851.PDF). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.