I have a GDPR art. 22 request from a customer. I need the list of automated decisions on their profile, last 90 days.
AGENT · POLICY MAPPER
Every automatic decision connects to the specific regulatory article.
Policy Mapper works on top of the runtime audit registry. For each automatic decision, it associates the reference to the specific article of the applicable regulation (AI Act, GDPR, DORA, IDD, MDR, sector regulations). Regulatory audit moves from a generic SQL query to evidence traced article by article.
Policy Mapper at work.
17 decisions found. 12 Lead Scoring (AI Act Annex III 5b + GDPR art. 22), 4 Compliance Scan (GDPR art. 5 + AI Act art. 13), 1 Wealth Copilot (MiFID II art. 25 + GDPR art. 22).
Shall I export the structured list as CSV for the customer response?
Yes, export it. I'll respond within 24h. Thank you.
Why it exists.
Audit Recorder captures every automatic runtime decision in an immutable registry. Policy Mapper adds the regulatory mapping layer: for each decision, it identifies the applicable regulation article — GDPR art. 22 for automated decisions on natural persons, AI Act Annex III for high-risk systems, DORA for significant operational incidents, IDD for insurance proposals, MDR for medical software.
How it annotates the registry per article.
The mapping changes how the compliance officer and the regulator read the registry. A SQL query can now extract 'all decisions involving GDPR art. 22 in the last 90 days' instead of 'all runtime decisions without regulatory categorisation'. The audit closes in hours, not weeks.
Mapping completeness stays with the compliance team.
Policy Mapper does not autonomously interpret new regulatory circulars. The mapping rules are declarative, written and kept current by the customer's compliance team.
DPO, compliance officer, head of risk.
DPO
Gets a regulatorily annotated audit registry. Queries for GDPR art. 22 audits (the right to an explanation of automated decisions), data access requests, and data protection authority audits become direct — no manual interpretation of the runtime log needed.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Sector compliance officer
For companies in the perimeters of Banca d'Italia, IVASS, AGENAS, and equivalent EU regulators: structured evidence article by article. The periodic audit closes in shorter times, with the trace already organised by regulation.
Proposal no. 2024-081 In review
Missing disclosure
MiFID II art. · regulated financial instrument
Alt. 1 …in compliance with MiFID II and applicable supervisory provisions.
Alt. 2 …with full disclosure attached to the offer document.
Audit trace recorded · 14:31
Head of risk
Sees the runtime's regulatory exposure aggregated by regulatory article. Operational risk analysis is grounded in structured data, not in retrospective reconstructions.
KYC case KYC-2024-091 In verification
ID document VERIFIED
Biometrics · SCA PSD2 LINKING OK
Beneficial owner BUSINESS REGISTRY
Case forwarded to AML Screening
A GDPR art. 22 request from a customer. The DPO responds within 24 hours.
A customer exercises the GDPR art. 22 right.
A bank has several Polyant agents in production. A customer exercises the right of access to data under GDPR art. 22: they want to know which automated decisions were taken on their profile.
Seventeen decisions in ninety days, mapped article by article.
The DPO opens the SQL client and runs a query on the audit registry filtered by customer and by the regulatoryReference field containing 'GDPR art. 22'. The structured output includes seventeen decisions: twelve Lead Scoring decisions with complete reason codes, four Compliance Scan decisions on commercial contracts, one Wealth Copilot decision with portfolio suggestions.
The DPO responds to the customer within twenty-four hours.
The DPO builds the response to the customer with the structured detail in twenty-four hours. Without Policy Mapper, the same operation would have taken weeks of manual reconstruction through unannotated logs.
Configuration and technical resources.
The rules are declarative. The customer's compliance, DPO and risk team defines in a readable format the mapping rules: for each type of runtime decision and each type of gate activated, the applicable regulatory article. The rules live in the customer's repository, versioned.
The completeness of the mapping against the sector's regulatory landscape is the responsibility of the customer's compliance team. When a regulator publishes new guidance (new AI Act circulars, DORA updates, national transposition of EU directives), the compliance team updates the rules. The agent runs the configured mapping; it does not autonomously interpret new regulatory texts.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector
- Integration
- native with the Polyant runtime audit registry (no external adapters required)
- Mapping rules
- declarative, versioned, written by the compliance + DPO + risk team
- Correctness note
- completeness of the mapping against the updated regulatory landscape is the responsibility of the customer's compliance team; the agent runs the configured rules
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on regulatory references
- Registry
- immutable update of the `regulatoryReference` field on `governance_events`; queryable with a standard SQL client
Frequently asked questions about the agent.
When a regulator publishes an update (new AI Act guidelines, national NIS2 transposition via implementing legislation, central bank circulars), the compliance team updates the mapping rules in the repository. The agent applies the updated rules to subsequent decisions. Previous decisions retain the original mapping (registry immutability).
Yes. Policy Mapper is natively integrated with the runtime audit registry. Every Polyant agent writes to the registry; Policy Mapper annotates the regulatoryReference field for each event, regardless of which agent generated the decision. No per-agent configuration is required.
No. The mapping rules are written and maintained by the customer's compliance team. The agent runs the configured rules; it does not have the capability to autonomously read new regulatory texts and update itself. The compliance team is responsible for keeping the rules repository current as the regulatory landscape evolves.
The typical pattern is 8-14 weeks. Discovery and regulatory perimeter mapping 2 weeks, mapping rule writing with compliance, DPO and risk 4-7 weeks, audit registry integration 1-2 weeks, hand-off 1-3 weeks. The main factor is the depth and complexity of the customer's regulatory perimeter.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Policy Mapper would configure to the customer's case. Which regulatory perimeter, which types of automatic runtime decisions, which relevant regulators.