Privacy & AI Governance by Design
Compliance is not a policy document. It’s a structural, auditable artifact — produced from how the system actually behaves. The Legal AI OS turns a Data Protection Impact Assessment into something provable, not a checkbox.
The Risk-Tier Framework — EU AI Act
Where legal-AI processing sits
The EU AI Act sorts AI systems by risk. Where any single deployment lands depends on what it does, who it affects, and how it’s used. The tiers below are the Act’s own categories. The placement note is reasoning, not a legal opinion on a specific deployment.
| Tier | What the Act requires | Legal-AI processing note |
|---|
Unacceptable
Prohibited |
Banned practices: subliminal manipulation, social scoring, real-time remote biometric ID in public spaces, exploitation of vulnerabilities. Not deployable, period. |
Document-processing and review AI does not fall into the prohibited categories. This tier is a hard floor no legal-AI deployment should approach. |
High
Most regulated |
Strict obligations: risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, cybersecurity. Must be assessed before market entry. |
Systems that materially affect legal rights could be high-risk. The platform is designed so deployments can be governed to meet these obligations — risk management, data governance, transparency, and human oversight are built in, ready when a deployment requires them. |
Limited / Minimal
Lighter duties |
Limited-risk systems carry transparency duties — users know they are interacting with AI. Minimal-risk systems face no additional obligations beyond existing law. |
Recommendation and document-processing tools often sit here. Transparency is met by surfacing that an AI produced the analysis, with the decision log as the record. |
Not a legal opinion. The tier a real deployment occupies depends on its specific purpose, subjects, and context of use. This framework shows how the Act is structured and how the platform is built to meet whatever tier a deployment lands in — including High-risk obligations when they apply.
DPIA — How It’s Generated
An assessment from real behavior, not self-reporting
A DPIA (and its algorithmic-impact cousin) is assembled from the system’s actual artifacts. What data flows, why, how long it’s kept, what wall it stays behind, who signed off. The output is an exportable, compliance-ready record.
STEP 1
Scope
What the processing does, the data categories, the purposes, the lawful basis under consideration.
→
STEP 2
Data inventory
Every field processed, where it comes from, where it’s stored, who can read it.
→
STEP 3
Risk identification
Risks to data subjects, drawn from actual access patterns and confidentiality boundaries.
→
STEP 4
Mitigations
What controls the system actually enforces: retention limits, ethical walls, minimisation.
→
STEP 5
Human sign-off
A named reviewer reviews and approves the assessment. Nothing ships unsigned.
→
STEP 6
Audit-ready artifact
Exportable report with cited evidence, versioned, ready for regulators and clients.
Data Inventory
Live mapping of fields processed, sources, and storage locations.
Retention Limits
Automated deletion and retention windows enforced in the system.
Confidentiality Walls
Ethical-wall isolation, including the platform’s Rule 1.6-style walls, structural not policy.
Traceability Logs
Every decision, override, and approval attributable to a person and a time.
NIST AI RMF Mapping
The RMF functions, mapped to platform capability
NIST AI RMF 1.0 organizes responsible AI into four functions: Govern, Map, Measure, Manage. Each maps to what the platform actually does.
G
Govern
Policies, roles, and accountability. Named owners, documented approvals, ethical walls, and a clear chain of who decides.
M
Map
Context and risks. A live data inventory and processing map show what’s processed, why, and by whom — the raw material for the DPIA.
M
Measure
Test and evaluate. Traceability logs, confidence scoring, and continuous monitoring quantify how the system performs against its risk profile.
M
Manage
Control and reduce risk. Human-in-the-loop oversight, escalation rules, and automated mitigation that the system enforces.
GDPR / CCPA Fundamentals
The core concepts the platform is built to support
A survey, not a treatise. These are the ground rules any legal-AI deployment in the EU or California operates under — and the ones the platform operationalizes.
Lawful basis
Processing must rest on a recognized basis under GDPR Art. 6. The assessment records which basis applies, rather than assuming it.
Purpose limitation
Data is collected for a stated purpose and used for that purpose. The platform ties each data flow to its declared purpose.
Data minimization
Only the data needed for the purpose is processed. Scoping limits what enters the pipeline in the first place.
Data subject rights
Access, rectification, erasure, portability. Traceability makes each right answerable — you can show what exists and remove it on request.
DPIA trigger — Art. 35
GDPR Art. 35 requires a DPIA where processing is likely to result in a high risk to individuals. Systematic AI evaluation of personal data is a classic trigger.
CCPA / CPRA rights
Know, delete, correct, and opt-out of sale or sharing of personal information. The audit trail supports responding to each request.
Why This Is The Specialization
Audit-ready compliance evidence
Regulated industries don’t buy feature lists. They buy the ability to prove how data is handled — to regulators, to clients, to their own boards. Most AI governance is a policy nobody reads after week one. This turns governance into software: structural walls, attributable logs, exportable impact assessments.
The specialization is confidence in a crowded market. Buyers in law, finance, and healthcare need someone who can show, not claim. That’s the standing this work builds.