Skip to content

AI Intake Approval Workflow

Project: Pickles GmbH — AI Governance Framework Stage: Stage 2 — Governance Foundation Status: Draft Version: v1 Date: 2026-02-22 Assumptions: Built on outline assumptions — not verified against real Pickles GmbH data

Purpose

This workflow defines the mandatory gate process that every AI system must pass before it may be deployed by or on behalf of Pickles GmbH [ASSUMPTION — A-001, A-003]. No AI system may be used with real client data, integrated into client-facing products, or made accessible to external users until it has completed all gates in this workflow and received final Deployment Approval at Gate 6.

The workflow applies to: - New AI systems being evaluated for procurement or development - Existing AI systems undergoing substantive modification (EU AI Act Article 3) - Third-party AI model integrations [ASSUMPTION — A-004] - Internal AI tools that access or process personal data

Regulatory basis: - EU AI Act Articles 3, 9, 11, 13, 14, 16-23 — Requirements prior to market placement - EU AI Act Article 72 — Post-market monitoring obligations triggered at deployment - GDPR Article 35 — Data Protection Impact Assessment prior to processing - GDPR Article 36 — Prior consultation with BfDI where residual high risk - GDPR Article 28 — Data Processing Agreement requirement before processing begins - BDSG Section 67 — German DPIA requirements - BDSG Section 69 — BfDI prior consultation (must be initiated at design stage, not post-deployment) [LEGAL REVIEW REQUIRED] - BRAK Position Paper Section 2.1 — Human oversight requirements prior to AI deployment in legal practice - ISO/IEC 42001 Clause 8.2 — AI risk and impact assessment requirements

Workflow Overview

INTAKE REQUEST
     │
     ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 1 — System Description                                    │
│  Complete system profile. No evaluation work until complete.    │
└──────────────────────────┬──────────────────────────────────────┘
                           │ PASS
                           ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 2 — Risk Classification                                   │
│  Assign Tier (High / Medium / Low) using L1-3.2 decision tree. │
└──────────────────────────┬──────────────────────────────────────┘
                           │ PASS
                           ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 3a — Data Review                                          │
│  Identify all personal data categories. Assess DPIA trigger.   │
└──────────────────────────┬──────────────────────────────────────┘
                           │ PASS
                           ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 3b — Data Review (DPIA / Prior Consultation)              │
│  Complete DPIA if triggered. Initiate BfDI consultation         │
│  if residual high risk. Skip if Tier 3 with no personal data.  │
└──────────────────────────┬──────────────────────────────────────┘
                           │ PASS
                           ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 4 — Legal and Regulatory Review                           │
│  EU AI Act compliance, BRAO/BRAK obligations, DPA review,       │
│  conformity assessment (Tier 1 only).                           │
└──────────────────────────┬──────────────────────────────────────┘
                           │ PASS
                           ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 5 — Engineering Sign-Off                                  │
│  Security review, logging configuration, monitoring setup,      │
│  technical documentation.                                       │
└──────────────────────────┬──────────────────────────────────────┘
                           │ PASS
                           ▼
┌─────────────────────────────────────────────────────────────────┐
│  GATE 6 — Deployment Approval                                   │
│  Final sign-off. System registered in AI System Inventory       │
│  (L1-3.1). Deployment Status set to Production.                │
└──────────────────────────┬──────────────────────────────────────┘
                           │ APPROVED
                           ▼
                     DEPLOYED TO PRODUCTION

BLOCKED systems at any gate are returned to the responsible person with a written blocking reason. Work may not proceed to the next gate until the block is resolved and the gate re-passed.

Gate Checklists

Gate 1 — System Description

Purpose: Capture a complete system profile before any evaluation or risk assessment begins. A system cannot be registered in L1-3.1 or assessed against L1-3.2 without a complete Gate 1 profile.

Responsible: System owner (named individual) [ASSUMPTION — A-008]

Checklist:

  • [ ] System name — the commercial or internal name of the system
  • [ ] Purpose and intended use — what the system does; what problem it solves; who will use it
  • [ ] Deployment scope — internal only, or customer-facing (triggering EU AI Act Article 50 obligations) [ASSUMPTION — A-006]
  • [ ] Model type — e.g., LLM, RAG, classification model, rule-based system
  • [ ] Third-party model provider identified [ASSUMPTION — A-004] — named provider or "to be confirmed at Gate 4"
  • [ ] Hosting location [ASSUMPTION — A-005] — EU-based cloud, German data centre, third-party API, etc.
  • [ ] Data categories — initial assessment of what personal data (if any) the system will process
  • [ ] Intended users — Pickles GmbH staff only; lawyer clients; lawyer clients' end clients; all three
  • [ ] System owner named — a specific named individual, not a job title, who will be responsible for ongoing compliance
  • [ ] Date of intake request recorded

Gate 1 pass criteria: All fields above complete and internally consistent. No blanks permitted.

Regulatory basis: EU AI Act Article 11 (technical documentation requirements begin at intake); EU AI Act Article 13 (transparency and instructions for use must be designed from the start).

Gate 2 — Risk Classification

Purpose: Assign a risk tier to the system using the Risk Classification Framework (L1-3.2). The tier determines all subsequent requirements. Risk classification must be confirmed before the system is registered in the AI System Inventory (L1-3.1) as anything other than "Pre-intake."

Responsible: Compliance Lead

Checklist:

  • [ ] Decision tree applied — worked through all questions in L1-3.2 Section 3 in sequence
  • [ ] Prohibited use check completed (L1-3.2 Q1) — confirm system does not fall within EU AI Act Article 5 prohibited practices; if yes, intake terminated and Legal notified
  • [ ] Tier assigned — High (Tier 1), Medium (Tier 2), or Low (Tier 3)
  • [ ] Classification rationale documented — specific criteria met or not met for each tier
  • [ ] [LEGAL REVIEW REQUIRED for Tier 1] — if Tier 1 classification is proposed, a qualified lawyer must review the classification before Gate 2 is passed; in particular Q2 (Annex III / Recital 61) and Q6 (specific-case reliance) require legal interpretation
  • [ ] Risk Classification field in L1-3.1 updated with tier and classification date
  • [ ] Next gate requirements determined based on tier (see Gate 3a below)

Gate 2 pass criteria: Tier assigned, rationale documented, and (for Tier 1) legal review completed. Classification entered in L1-3.1.

Regulatory basis: EU AI Act Articles 6, 9 (risk-based requirements apply from design stage); EU AI Act Annex III and Recital 61 (legal AI classification triggers); ISO/IEC 42001 Clause 8.2.

Gate 3a — Data Review (Initial)

Purpose: Identify all personal data categories that the system will process and determine whether a DPIA is required before processing begins.

Responsible: DPO [ASSUMPTION — A-008] (with input from system owner and Engineering)

Checklist:

  • [ ] Personal data categories mapped — list all categories the system will process: general personal data (GDPR Article 4); special categories (GDPR Article 9(1)); criminal convictions (GDPR Article 10); no personal data
  • [ ] Data subjects identified — whose personal data: lawyer clients; their end clients; Pickles GmbH staff; third parties appearing in legal documents
  • [ ] Data flows documented — where data enters the system, where it is processed, where it is stored, where it exits [ASSUMPTION — A-005 on hosting]
  • [ ] Sub-processors identified — third-party model providers [ASSUMPTION — A-004] and any cloud infrastructure providers
  • [ ] DPIA trigger assessed against GDPR Article 35 and BDSG Section 67 criteria:
  • [ ] Large-scale processing of special categories (Article 9(1)) or criminal data (Article 10)
  • [ ] Systematic and extensive profiling with legal or significant effects
  • [ ] Systematic monitoring of publicly accessible areas (not applicable to legal AI — note only)
  • [ ] Other criteria in the BfDI or EDPB lists of processing operations requiring DPIA
  • [ ] DPIA trigger conclusion documented — DPIA required / not required (with reasoning)

Gate 3a pass criteria: All data categories mapped. DPIA trigger assessment documented with conclusion.

Regulatory basis: GDPR Articles 35, 36; GDPR Article 28 (processor obligations triggered when personal data processing confirmed); BDSG Section 67.

Gate 3b — Data Review (DPIA and Prior Consultation)

Purpose: Complete the DPIA where required and initiate BfDI prior consultation if residual risk remains high after mitigations. This gate is mandatory for Tier 1 systems and required for Tier 2 systems where Gate 3a determines a DPIA is triggered. Tier 3 systems with no personal data may proceed directly to Gate 4.

Responsible: DPO (with Legal and Engineering input) [ASSUMPTION — A-008]

Checklist:

  • [ ] DPIA completed (where triggered) per L2-5.2 template — covering:
  • [ ] Systematic description of processing operations and purposes (GDPR Article 35(7)(a))
  • [ ] Assessment of necessity and proportionality (GDPR Article 35(7)(b))
  • [ ] Assessment of risks to rights and freedoms of data subjects (GDPR Article 35(7)(c))
  • [ ] Measures to address risks and demonstrate GDPR compliance (GDPR Article 35(7)(d))
  • [ ] Data Processing Agreement (DPA) drafted under GDPR Article 28 if Pickles GmbH acts as processor [ASSUMPTION — A-007] — template at Stage 3
  • [ ] Vendor DPA assessed for any third-party model provider [ASSUMPTION — A-004] — template at L2-5.3
  • [ ] Section 43e BRAO service agreement assessed for lawyer clients [ASSUMPTION — A-002] [LEGAL REVIEW REQUIRED]
  • [ ] Residual risk assessed — high, medium, or low after mitigations applied
  • [ ] BfDI prior consultation initiated if residual high risk (GDPR Article 36; BDSG Section 69) [LEGAL REVIEW REQUIRED — must be initiated at design stage, not post-deployment]
  • [ ] DPO sign-off recorded on DPIA conclusion and residual risk assessment

Gate 3b pass criteria: DPIA complete (where required); DPAs in place or in progress; BfDI consultation initiated where required; DPO sign-off recorded.

Regulatory basis: GDPR Articles 28, 35, 36; BDSG Sections 67, 69; BRAO Section 43e [ASSUMPTION — A-002].

Purpose: Confirm that the system as designed and documented complies with all applicable regulatory obligations. For Tier 1 systems, this includes the EU AI Act conformity assessment. For all customer-facing systems, this includes BRAK professional obligation review.

Responsible: Legal (qualified lawyer with EU AI Act expertise) and Compliance Lead

Checklist:

For all tiers: - [ ] EU AI Act obligations confirmed for the assigned risk tier — documentation, transparency, logging, human oversight requirements all planned and feasible - [ ] AI transparency disclosure designed for customer-facing systems (EU AI Act Article 50) [ASSUMPTION — A-006] - [ ] Human oversight design reviewed against L1-3.4 — confirm no fully automated legal advice output; mandatory review steps designed in - [ ] Legal review of classification rationale for Tier 1 systems (if not already completed at Gate 2)

Tier 1 additional requirements: - [ ] Conformity assessment process initiated (EU AI Act Articles 16-23) — internal conformity assessment or notified body assessment as applicable - [ ] Technical Documentation Pack initiated (EU AI Act Article 11) — template L2-4.2 - [ ] EU AI Act Article 13 transparency content drafted — instructions for use, known limitations, human oversight requirements, intended purpose statement - [ ] Declaration of Conformity pathway confirmed (EU AI Act Article 47)

BRAK / professional obligation review (for lawyer-facing systems): - [ ] Anwaltgeheimnis compliance assessed — professional secrecy obligations satisfied [ASSUMPTION — A-002] - [ ] Section 43e BRAO IT outsourcing requirements satisfied — where system relies on a third-party provider [ASSUMPTION — A-004] [LEGAL REVIEW REQUIRED] - [ ] BRAK professional liability framework reviewed — responsibility allocation between Pickles GmbH and lawyer client documented

Gate 4 pass criteria: Legal sign-off documented. All Tier 1 conformity assessment steps initiated. Customer-facing transparency content drafted. No unresolved legal blockers.

Regulatory basis: EU AI Act Articles 6, 9, 11, 13, 16-23, 47, 50; BRAO Section 43e; BRAK Position Paper December 2024 Section 2.1.

Gate 5 — Engineering Sign-Off

Purpose: Confirm that the technical implementation satisfies all security, logging, monitoring, and documentation requirements for the assigned risk tier before deployment proceeds.

Responsible: Engineering Lead (with Security review where applicable)

Checklist:

For all tiers: - [ ] Security review completed — at minimum: access controls, authentication, data in transit (encryption), data at rest (encryption), input validation, output sanitisation - [ ] Logging configured as required for tier: - Tier 1: Automatic logging mandatory (EU AI Act Article 12; BDSG Section 76) — logging of inputs, outputs, oversight decisions, anomalies - Tier 2: Operational logging of interactions and errors - Tier 3: Basic system logging - [ ] Hosting location confirmed as EU-based [ASSUMPTION — A-005]; if not EU-based, flag immediately to Legal and DPO for Article 44-49 GDPR transfer assessment - [ ] Monitoring configured per L3-6.1 requirements for tier: - Tier 1: Continuous active monitoring with KPIs defined - Tier 2: Periodic monitoring (minimum quarterly) - Tier 3: Annual review schedule set

Tier 1 additional requirements: - [ ] Technical Documentation Pack (L2-4.2) complete — all required sections populated - [ ] Human oversight mechanisms tested — system cannot produce outputs that bypass mandatory review step - [ ] Audit trail tested — logging captures events required under EU AI Act Article 12 - [ ] Incident response integration tested — system feeds into L3-6.2 Incident Response Playbook

Tier 2 additional requirements: - [ ] AI interaction transparency implemented — EU AI Act Article 50 disclosure active for any system that interacts with natural persons

Gate 5 pass criteria: Engineering sign-off recorded. All tier-specific logging and monitoring configured and tested. No unresolved security issues.

Regulatory basis: EU AI Act Articles 9, 11, 12, 14; GDPR Article 32; BDSG Section 64 (technical controls); BDSG Section 76 (audit logging).

Gate 6 — Deployment Approval

Purpose: Final cross-functional sign-off confirming all gates have been passed, all documentation is complete, and the system is authorised to proceed to Production status.

Responsible: See sign-off authority table below.

Checklist:

  • [ ] All previous gates confirmed passed — written records of Gate 1-5 completions on file
  • [ ] AI System Inventory (L1-3.1) entry complete and accurate — all fields populated with verified information; no placeholders
  • [ ] Deployment Status set to "Staging" before any production traffic; Production only after this gate is passed
  • [ ] Monitoring Status set to "Active Monitoring" (Tier 1/2) or "Not Required" (Tier 3) in L1-3.1
  • [ ] System owner confirmed — named individual (not job title) recorded in L1-3.1
  • [ ] Incident response pathway confirmed — system owner and Engineering Lead know the escalation pathway per L3-6.2
  • [ ] Post-market monitoring plan active (EU AI Act Article 72 for Tier 1) — KPIs defined, monitoring schedule set
  • [ ] First review date scheduled in L1-3.1

Sign-off authority by tier:

Tier Required Sign-Offs
Tier 1 — High Risk (1) Legal and Compliance Lead; (2) DPO [ASSUMPTION — A-008]; (3) Engineering Lead; (4) CEO or designated C-suite executive
Tier 2 — Medium Risk (1) Compliance Lead; (2) Engineering Lead
Tier 3 — Low Risk (1) Engineering Lead

Gate 6 pass criteria: All required sign-offs obtained and documented. L1-3.1 entry complete. Deployment Status set to Production.

Regulatory basis: EU AI Act Articles 16-23 (obligations of providers before market placement); EU AI Act Article 72 (post-market monitoring obligation begins at deployment); ISO/IEC 42001 Clause 8.4 (deployment requirements).

Substantive Modification Process

A deployed system that undergoes substantive modification must re-enter this workflow at the appropriate gate. A modification is substantive under EU AI Act Article 3(23) if it affects the intended purpose, the AI model or its performance, or the risk level of the system.

Modification Type Re-entry Point Notes
Change to AI model architecture or provider Gate 2 Re-run full risk classification; may require new conformity assessment
Change in intended purpose or deployment scope Gate 2 Scope change may change risk tier
Change in data categories processed Gate 3a Re-assess DPIA trigger
Change from internal to customer-facing Gate 2 Likely triggers transparency obligations and tier upgrade
Change of third-party model provider [ASSUMPTION — A-004] Gate 3b New vendor DPA required; re-run L2-5.3
Security or infrastructure change affecting logging Gate 5 Engineering re-sign-off required
Minor bug fix or performance change without scope change No re-entry Document in change log; confirm not substantive per Article 3(23)

[LEGAL REVIEW REQUIRED] The definition of "substantive modification" under EU AI Act Article 3(23) requires legal interpretation in each specific case. When in doubt, treat a modification as substantive and re-enter the workflow.

Roles and Responsibilities

Role Responsibility in This Workflow
System Owner (named individual) Initiates intake; completes Gate 1; responsible for ongoing compliance post-deployment
Compliance Lead Leads Gate 2 (risk classification) and Gate 4 (legal/regulatory review); final compliance sign-off for Tier 2
DPO [ASSUMPTION — A-008] Leads Gate 3a and Gate 3b (data review and DPIA); DPO sign-off for Tier 1 and any system triggering DPIA
Legal Gate 4 legal review; Tier 1 classification review; BRAO/BRAK compliance confirmation
Engineering Lead Gate 5 technical review; Engineering sign-off; post-deployment monitoring configuration
CEO / C-suite Gate 6 final sign-off for Tier 1 systems only

Blocked System Protocol

If a system is blocked at any gate:

  1. Written blocking reason produced by the gate reviewer within 2 business days of assessment
  2. Blocking reason communicated to the system owner and recorded against the system in L1-3.1
  3. System status remains "Development" or "Staging" — may not advance to Production
  4. Resolution pathway agreed — system owner and gate reviewer agree remediation steps
  5. Re-assessment — system re-presents at the blocked gate; previous gate completions remain valid unless the modification affects them

A system that is blocked and subsequently abandoned must have its L1-3.1 entry updated to "Suspended" or "Decommissioned" with a reason noted.

This workflow is a governance control document. Completion of all gates is a prerequisite for deployment. No exceptions.

[LEGAL REVIEW REQUIRED] The application of this workflow to specific Pickles GmbH systems requires legal review before operational use. In particular: Gate 2 risk classification for legal AI tools; Gate 3b BDSG Section 69 prior consultation timing; and Gate 4 Section 43e BRAO compliance for any system relying on a third-party AI model provider.