Build an accurate AI inventory directly from source code, trace personal and sensitive data flowing into LLM prompts and AI APIs, and produce the Article 11 technical documentation EU AI Act compliance expects. Code-based evidence, before anything reaches production.
The regulation is in force, with prohibitions and General-Purpose AI rules already enforceable. The Digital Omnibus agreement of 7 May 2026 deferred the headline high-risk deadlines, but several obligations apply immediately and the work to meet them takes time.
Compliance leaders know which Articles apply. The harder question is how to gather evidence that the application actually behaves the way the documentation says it does. Most organizations hit the same four walls.
Engineering ships OpenAI, Anthropic, Gemini, and agent-framework integrations through pull requests. None of these reach procurement. Spreadsheets and questionnaires drift the moment a new SDK lands. Risk classification under Article 6 is impossible without a current inventory of what your application actually calls.
AI Act Art. 6 · Art. 11PII exposures to AI integrations are rarely intentional. They happen as codebases grow. A developer prints a full user object, a tainted variable carries PHI through a chain of transformations, and by the time anyone notices, the data has already been logged or sent to a third party. Article 10 data governance and GDPR Article 9 special categories apply, but the evidence lives in source code, not in a runtime log.
AI Act Art. 10 · GDPR Art. 9Agile teams ship every week. Technical documentation written at design time is stale before the next sprint. Retrofitting design history across dozens of services to satisfy Annex IV expectations is the work most compliance teams underestimate, and the work auditors examine first.
AI Act Art. 11 · Annex IVPersonal data entering an AI system is governed by both regimes. A single oversharing flow can trigger GDPR Article 32 security violations, Article 35 DPIA gaps, and AI Act Article 10 data-governance findings at the same time. Two regulators, two penalty schedules, one root cause.
GDPR Art. 32 / 35 · AI Act Art. 10The AI Act is risk-based. Obligations escalate with the potential harm a system could cause. The four tiers determine what your team has to produce and which deadline applies to you.
Spam filters, recommendation engines, inventory optimization, and most general AI use. Providers are encouraged to adopt voluntary codes of conduct. No specific obligations.
Chatbots, generative AI, emotion-recognition systems, and biometric categorization. Users must be told they are interacting with AI. AI-generated content must be machine-readable as synthetic. Applies from 2 August 2026.
Annex III systems in recruitment, credit scoring, education, employment, law enforcement, migration, and justice. Plus Annex I product-embedded AI in regulated products. Risk management, data governance, technical documentation, logging, human oversight, and registration in the EU database.
Social scoring, subliminal manipulation, untargeted facial scraping, emotion recognition in workplaces and schools, real-time biometric identification in public spaces. New for December 2026: AI-generated CSAM and non-consensual intimate imagery.
HoundDog.ai operates inside the development pipeline, tracing how sensitive data actually flows to AI systems as code is written and changed. Scans run locally. Your code never leaves your machine.
Static analysis recognizes more than 1,000 integrations out of the box, including direct LLM SDKs (OpenAI, Anthropic, Gemini, Mistral) and AI agent frameworks (LangChain, LlamaIndex, CrewAI, PydanticAI, Semantic Kernel). Every AI integration is flagged the day engineering adds it, with the file, function, and call site identified.
This becomes the foundation for risk classification under Article 6. You cannot decide whether a system is Annex III high-risk without knowing what it actually is.
AI Act Art. 6 · Art. 11Taint-flow static analysis follows sensitive fields across files, functions, and procedures, then flags them when they reach a data sink. Each AI-bound flow is rated safe or risky against customizable allowlists per provider.
New AI integrations and the categories of personal data they process become suggested edits in your Org RoPA and AI inventory, each traceable to the code that generated it. The privacy team reviews and approves every change.
Auto-generate Data Protection Impact Assessments pre-populated with detected AI data flows and risks, aligned with the EU AI Act, GDPR, HIPAA, and other frameworks. Because the documentation is grounded in actual processing behavior, it satisfies Article 11's expectation that records reflect what the system does.
AI Act Art. 11 · GDPR Art. 30, 35
Bake your AI policy into the pipeline. Define which data categories are allowed per AI provider, and block unsafe flows when they are introduced in pull requests. Default allowlists ship out of the box: an internal LLM endpoint's allowlist differs from a public AI API.
Unapproved AI data sharing is addressed while context is fresh and remediation costs are low. Preventive enforcement turns governance from advisory documents into operational controls, which is the spirit of GDPR Article 25 privacy by design and what AI Act conformity reviews look for.
AI Act Art. 9 · GDPR Art. 25
A side-by-side view of where the regulation makes specific requirements and the code-based evidence HoundDog.ai surfaces for each. Designed to be shared with auditors and DPOs.
| Requirement | What it asks for | Code-based evidence from HoundDog.ai |
|---|---|---|
| AI inventory Art. 6, foundational |
Identify which AI systems the application uses so risk tier can be assigned. | Static analysis enumerates every AI integration in source code, including SDK-based and indirect agent-framework usage, with file and call-site provenance. |
| Data governance AI Act Art. 10 |
Document categories of personal and sensitive data processed by AI systems. | Taint-flow analysis traces 100+ data types into each AI sink, categorized as PII, PHI, CHD, secrets, or special-category data under GDPR Art. 9. |
| Risk management AI Act Art. 9 |
Identify, evaluate, and mitigate risks throughout the system lifecycle. | Risky data flows are surfaced at PR time with severity rating, providing a continuous risk register tied to code changes rather than periodic reviews. |
| Technical documentation AI Act Art. 11, Annex IV |
Maintain records of design, data, validation, and monitoring sufficient for authority review. | Every scan produces reproducible evidence of which AI systems are called, what data they receive, and from where, exportable as audit-ready artifacts. |
| Record-keeping AI Act Art. 12 |
Automatic logging of events relevant to risk identification and post-market monitoring. | Code-level provenance for every detected flow: repository, file, line, function. Persistent and queryable across scans, with diffs between runs. |
| Transparency AI Act Art. 50, from Aug 2026 |
Disclose AI interactions to users. Mark AI-generated content as synthetic. | Classification of detected AI usage (generative, chatbot, decision-support) helps determine which Article 50 disclosures apply per feature. |
| Privacy by design GDPR Art. 25 |
Build minimization, access controls, and protection into the architecture from the start. | CI integration blocks unapproved AI data sharing in pull requests, shifting privacy enforcement to design and development phases. |
| DPIA GDPR Art. 35 |
Assess and document high-risk processing before it begins. | Auto-generate Data Protection Impact Assessments pre-populated with detected data flows, AI integrations, and identified risks. |
| Records of Processing GDPR Art. 30 |
Maintain a register of processing activities and subprocessors. | New AI integrations and subprocessors appear as suggested RoPA edits for privacy team review and approval, traceable to the code change. |
Watch a live demo of HoundDog.ai discovering AI integrations from source code, tracing PHI and PII into LLM prompts, and turning each finding into the kind of evidence Article 11 technical documentation expects, before anything ships.
A walkthrough of the scanner running against a real codebase, surfacing AI integrations, tracing sensitive data into prompts, and producing the artifacts privacy, security, and compliance teams need to demonstrate readiness.
Watch NowAt development speed. Prevent risks instead of documenting them after the fact, with privacy teams in control: the engine proposes, the DPO approves.
All third-party and AI integrations detected directly in source code, including Shadow AI, whether the data flows through an SDK or API, with 1,000+ integrations covered out of the box.
Trace 100+ sensitive data types (PII, PHI, CHD, auth tokens) across code paths and into every data sink, including logs, storage, APIs, third-party, and AI integrations.
Keep your RoPA updated as new categories of personal data and subprocessors are introduced, detected directly from source code.
Validate design-phase privacy reviews with code-based evidence before code is pushed to production.
The AI Act does not replace GDPR. Personal data flowing into AI systems is still governed by GDPR, with full penalties. The two regimes overlap at every layer of an AI feature, so the safest assumption is that both apply.
| Topic | What this means for LLM use | Primary legal basis | Maximum penalties |
|---|---|---|---|
| Lawful basis | A valid lawful basis must be selected before any personal data is processed by the model or provider. | GDPR Art. 6 | Up to 20M EUR or 4% of global revenue |
| Special categories | Special categories cannot be processed unless an Article 9 exception applies with strong safeguards. | GDPR Art. 9 | Higher tier penalties |
| Privacy by design | Controls for minimization, access, and protection must be built into the architecture from the start. | GDPR Art. 25 | Higher tier penalties |
| Security of processing | Encryption, logging, and strong access controls must be in place across AI data paths. | GDPR Art. 32 | Penalties scale with severity |
| Transparency and user rights | Users must be informed and allowed access, correction, deletion, and objection over their data. | GDPR Art. 12-15, 21 | Penalties vary |
| International transfers | Valid transfer mechanisms and documented assessments are required when AI providers operate outside the EU. | GDPR Art. 44-49 | Penalties vary |
| Prohibited AI practices | Social scoring, manipulation, untargeted biometric scraping, and emotion recognition at work or school are banned. | AI Act Art. 5 | Up to 35M EUR or 7% of global turnover |
The methods most teams reach for first were not designed for a regulation that requires reproducible technical documentation of what the application actually does at the code level.
Stale by the time code ships. Even when engineers answer accurately, the answers reflect a snapshot. A new AI SDK landing the following week is invisible to the questionnaire until the next review cycle.
Useful for monitoring production traffic, but only see what has already shipped. They cannot block an oversharing flow at PR time, and they cannot tell you which feature introduced it. Detection without prevention.
Does not scale to the velocity of AI SDK adoption. Reviewers miss indirect AI calls embedded inside agent frameworks. Coverage drops with team size, exactly when AI integrations multiply.
Drift the moment a developer adds a new SDK. The version signed off in design is not the version running in production. Auditors notice the gap. Article 11 expects records that reflect what the system does today.
Operational AI governance: keep your AI inventory and RoPA in sync as engineering ships new integrations.
Related Use CaseCatch data processing agreement violations from third-party oversharing as they are introduced in code.
The Articles, deadlines, and roles teams ask about most when scoping their AI Act program.
Build an accurate AI inventory, trace personal data into every LLM prompt, and produce the Article 11 technical documentation your auditors will ask for. From source code, before anything ships.