AiGov: Human-Governed GDPR Audits

A Codex-built GDPR audit workbench where AI proposes scope, evidence requests, obligations, and checks; human auditors control every decision, with the case reconstructed from records.

Comment

Inspiration## How this started

I started AiGov without coding experience and without professional GDPR-auditing experience.

At first, the problem looked deceptively simple: collect the relevant documents, ask an AI to analyse them, and generate a compliance report.

The more I learned, the more obvious it became that this approach was wrong.

A professional GDPR audit is not a document-summarisation task. The auditor must understand the particular organisation, processing activities, systems, actors, purposes, data flows and available evidence. The auditor must decide what is relevant, what remains unknown, which obligations apply and how each obligation should be tested.

The same customer-service chatbot may therefore require a different audit depending on who operates it, what data it processes, how it is integrated, which providers are involved and what evidence actually exists.

The central question became:

How can an AI agent perform substantial audit work without turning the audit into an unexplained AI opinion?

The dead ends

I explored several architectural directions before reaching the current approach.

A deterministic audit flow

My first approach was to model the audit as a deterministic sequence of stages.

This initially appeared safe and controllable. However, the process rapidly exploded into branches and exceptions. GDPR auditing requires case-specific reasoning: different facts activate different obligations, missing evidence changes the next task, and one human decision may affect several later parts of the audit.

A deterministic workflow could coordinate individual tasks, but it could not represent the audit itself without becoming extremely complex.

A standalone agent application

I then explored building an independent agent application, including LangGraph-based orchestration.

This was useful for understanding state, checkpoints and human gates. However, it still encouraged me to represent the audit as a predefined graph. It also risked creating two competing environments: the agent’s working context and the application’s representation of the case.

The orchestration framework was beginning to define how the auditor had to think, instead of supporting the auditor’s case-specific reasoning.

The coding agent as the audit environment

The important change was recognising that a coding agent such as Codex already possesses many of the capabilities required by an auditor’s working environment.

A coding agent can:

  • read large and varied document collections;
  • navigate structured repositories;
  • call specialised tools;
  • execute bounded tasks;
  • maintain structured artifacts;
  • reason across evidence, methodology and instructions;
  • test its outputs;
  • pause for human decisions;
  • resume work from durable records.

Instead of building another general-purpose agent platform, AiGov can structure the coding agent itself as the main audit-working environment.

The surrounding application then has a clearer role: it presents the case to the human auditor, enforces professional decision gates and stores the authoritative audit history.

The application is not the brain of the audit, and the agent is not the final decision-maker.

This is the architecture I am now proving.

The main challenges

Creating an executable GDPR audit methodology

I could not find an official, agent-executable methodology specifically for auditing customer-service chatbots.

Legal requirements alone are insufficient. The agent also needs a methodology explaining how to move from case facts and evidence to:

  • scope and limitations;
  • potentially applicable obligations;
  • individual audit checks;
  • evidence requests;
  • observed behaviour;
  • findings and conclusions.

The methodology must be detailed enough for an agent to follow, while remaining flexible enough for professional, case-specific reasoning.

Integrating different forms of audit work

A chatbot audit combines tasks that are usually handled by different tools:

  • extracting and normalising client documents;
  • understanding the system and processing context;
  • defining scope and limitations;
  • selecting applicable GDPR obligations;
  • converting obligations into individual checks;
  • preparing documentary evidence requests;
  • interacting with the chatbot through tools such as Inspect or Petri;
  • collecting and matching telemetry;
  • comparing declared behaviour with observed behaviour;
  • preserving the provenance of evidence and decisions.

The challenge is not only running each task. It is keeping all of them connected inside the same durable audit case.

Bounding the agent’s reasoning

The agent needs legal and methodological reasoning capability, including the general GDPR knowledge of the underlying model. However, the audit cannot rely on that internal knowledge as an invisible source of authority.

This creates a narrow design line:

  • the model may use its knowledge to generate hypotheses, questions and proposed interpretations;
  • authoritative legal and methodological statements must come from explicit, versioned sources;
  • every proposal must connect to the particular case evidence;
  • uncertainty and missing information must remain visible;
  • unsupported assumptions must never become audit facts.

The goal is not to prevent the model from reasoning. It is to make its reasoning bounded, inspectable and challengeable.

Designing meaningful human control

This became the most important challenge.

A human gate cannot simply be an “Approve AI answer” button.

The auditor must see:

  • exactly what the agent is proposing;
  • why it is being proposed;
  • which evidence, legal sources and methodology support it;
  • what remains uncertain;
  • what will change if the proposal is accepted.

Each material proposal must therefore become a specific case object. The auditor can then:

  • accept it as proposed;
  • amend it and record the correction;
  • reject it while preserving the proposal and rationale;
  • defer it when additional evidence is required.

The decision is stored together with its target, rationale, source versions and effect on the audit case.

This introduces two different recovery requirements:

  1. Reconstruction: rebuilding the same audit state from stored records after the interface or agent session is restarted.
  2. Selective reconsideration: when earlier evidence or a human decision changes, identifying which downstream work is affected and reassessing it without discarding unaffected work.

The current demonstrator proves reconstruction. Selective reconsideration is the next architectural challenge and will require explicit dependencies between evidence, decisions, obligations, checks and later conclusions.

Designing an interface for professional work

The auditor should not need to inspect agent logs, repository files or development metadata.

The interface must show:

  • the current professional decision;
  • the agent’s proposal and reasoning;
  • relevant case evidence;
  • available human actions;
  • completed and upcoming decisions;
  • obligations and their associated checks;
  • a durable decision log.

The UI must simplify the interaction without hiding the information required for a defensible audit.

Finding architectural precedent

I researched assurance-case tools, legal workbenches, audit-management systems, evidence-review platforms and workflow engines.

I found useful individual patterns—claim-and-evidence structures, workpapers, approval chains, case files and change alerts—but no open-source solution combining:

  • coding-agent reasoning;
  • an executable audit methodology;
  • legal and evidential provenance;
  • human decision authority;
  • durable case state;
  • reconstruction;
  • selective reconsideration.

AiGov therefore combines ideas from several professional fields rather than adapting one existing application.

How I built it

Codex has been both the development environment and the inspiration for the product architecture.

I used Codex to:

  • explore and organise a large repository of legal, methodological and technical artifacts;
  • develop the first chatbot-audit methodology;
  • design and test document-extraction and audit skills;
  • run bounded audit tasks;
  • create realistic case materials;
  • implement the audit-case storage layer;
  • build the auditor-facing demonstrator;
  • diagnose failures and create integration tests.

The current demonstrator uses:

  • Python for the application and audit services;
  • SQLite for durable case records and event history;
  • an immutable prepared baseline with separate auditor review records;
  • a lightweight HTTP API;
  • HTML, CSS and JavaScript for the auditor workspace;
  • record-based reconstruction instead of relying on browser or conversation state;
  • automated tests for persistence, human decisions, baseline isolation and reconstruction.

The coding-agent environment performs and coordinates audit work. The web application acts as the auditor-facing decision and case-state surface. SQLite records remain the authoritative audit history.

What currently works

The current demonstrator uses a realistic fictional customer-service chatbot case.

An auditor can:

  1. open the audit case and inspect its supporting materials;
  2. navigate the audit process through a Decision Navigator;
  3. review proposed questions needed to establish scope;
  4. accept one proposed question;
  5. amend another and provide professional reasoning;
  6. reject another with a recorded rationale;
  7. review the resulting revised question set;
  8. provide final human approval;
  9. reconstruct the review from stored records and recover the same decisions.

The prepared case remains unchanged while the auditor’s decisions are stored separately in a SQLite-backed record and event ledger.

The current questions are deliberately fixed. This isolates and proves the human interaction, persistence and reconstruction mechanisms before introducing live agent reasoning.

The next milestone is to let the coding agent read the available case documents, follow the methodology and generate those questions itself while using exactly the same human decision mechanism.

What I learned

The most important object is not the prompt or the AI conversation.

It is the durable audit case.

A coding agent can become an auditing framework when it is surrounded by:

  • an explicit professional methodology;
  • authoritative legal and case sources;
  • bounded task-specific instructions and tools;
  • durable case objects;
  • provenance and versioning;
  • enforced human decision gates;
  • reconstruction and reconsideration rules.

This changes the role of the coding agent. It is no longer only a tool for writing software. It becomes an environment in which professional work can be prepared, connected, tested, challenged and revised.

The coding agent does not replace the auditor.

It performs substantial audit work while the human auditor retains professional authority.

The product vision

The complete AiGov environment will begin with client documents and continue through:

  1. document extraction and case orientation;
  2. missing-information requests;
  3. scope and limitations;
  4. obligation selection;
  5. individual audit checks;
  6. documentary evidence collection;
  7. live chatbot interaction;
  8. telemetry analysis;
  9. findings and reporting.

At each material point, the agent will propose the next justified audit work based on the current case, evidence, methodology and legal sources.

The human auditor will remain at the gates, controlling every important decision.

When new evidence arrives or an earlier decision changes, the system will preserve the audit history, show what is affected and reconsider only the relevant work.

The result should not be another AI-generated compliance score or unexplained report.

It should be a reconstructable professional audit performed with an AI working agent and governed by a human auditor.

Built With

Share this project:

Updates