Automated Scanning: Continuous Telemetry and Scan Pipelines

Article 10(2)(f) and (g) require training, validation and testing datasets to be examined for biases likely to affect health, safety or fundamental rights, with appropriate measures to detect, prevent and mitigate them. Article 15 requires high-risk systems to achieve appropriate accuracy, robustness and cybersecurity, including resilience against data poisoning, model poisoning, adversarial examples and confidentiality attacks, and to declare the metrics in the instructions for use under Article 15(3). You cannot declare a metric you have never measured.

For generative and language-model systems this is not theoretical. Prompt injection can subvert instructions, a model can be induced to disclose training data or system prompts, and outputs can be steered into prohibited content. An undocumented LangChain or Transformers import can turn a supposedly conventional service into an in-scope AI system overnight. Article 15 makes resilience a legal requirement, not a security nice-to-have.

Testing where the data goes is itself a compliance question. Sending prompts, outputs or database rows to a third-party analysis service is a processing operation and, if that service sits outside the EEA, a Chapter V transfer you must then justify. The evidence has to be produced without creating a new transfer problem.

Article 9's risk-management duty is continuous across the entire lifecycle. A scan performed once at launch and filed does not satisfy it. Evidence must be reproduced after any material change, whether a model version, a prompt, a guardrail or a data source, and must be traceable to when it was produced and what it found.

Scheduled scan jobs. Each scan runs as a short lived job on infrastructure we operate in Europe. It fetches only the data it needs, runs the selected engine, writes the findings, and shuts down. Nothing persists afterwards, and every job is scoped to your organisation and visible in the Scan Jobs table.

Twelve scan engines, each mapped to a framework obligation. Syft builds the software bill of materials and detects AI frameworks such as LangChain, Transformers, Torch and ONNX, which is what powers Shadow AI detection. Presidio with GLiNER finds personal data and GDPR Article 9 special-category data in Postgres, scored per record. Prowler checks cloud posture against CIS benchmarks. Trivy lists vulnerable dependencies and containers. The identity audit checks for dormant accounts and missing multi-factor authentication. The endpoint audit checks Intune and Jamf device compliance. Giskard, Modelscan and Compl-AI test language-model robustness, prompt injection and model artifact integrity. Findings are tagged by framework so they flow to the right checklist automatically.

Local scrubbing before storage. Presidio's Anonymizer replaces names, email addresses, national IDs and Article 9 attributes in memory before any metadata is written. Only the finding type, severity, framework and a salted location hash are kept. No personal data is sent to a US-owned service for analysis, so there is no cross-border transfer to justify under GDPR Chapter V.

Shadow AI detection. When a scan finds an AI framework in a repository or container that your inventory still lists as a conventional system, the platform promotes it to AI, raises a warning, and flags the risk classification for review. The scan result is attached as dated evidence feeding the Article 10 and 15 checklist items and the Article 72 post-market monitoring record.