Skip to main content

EU AI Act Compliance in Your CI/CD Pipeline

What the Act requires that a CI/CD pipeline can evidence, three pipeline stages, how Scanara’s GitHub merge gate works and where rule-based scans stop.

The Act does not require CI/CD. Providers of high-risk AI systems must keep technical documentation current (Article 11) and test before market placement or putting into service (Article 9(8)). They must also run a quality management system (Article 17). A pipeline can produce evidence for these duties.

These duties apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I). Article 2 lists exclusions. Fines reach up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: map each pipeline stage to the article it evidences.

A pipeline can evidence these duties; it cannot decide compliance

  • Technical documentation stays current (Article 11)

    Technical documentation is drawn up before market placement or putting into service and kept up to date. It contains at least the Annex IV elements. A pipeline step can check that required documents exist and change together with the code.

  • Tests run before market placement or putting into service (Article 9(6) to (8))

    Testing takes place at any time during development and in any event before market placement or putting into service, against prior defined metrics and probabilistic thresholds suited to the intended purpose. Pipeline test stages with fixed thresholds produce dated results.

  • Quality management covers change control (Article 17(1))

    The quality management system documents design control, development quality control, test and validation procedures and the management of modifications. Pipeline logs and review rules can record these steps.

  • Substantial modifications need a new conformity assessment (Article 43(4))

    A change to a system after market placement that the initial conformity assessment did not foresee, and that affects compliance with the Section 2 requirements or changes the intended purpose, is a substantial modification (Article 3(23)). A pipeline can flag changes to the model or the intended purpose for human review. It cannot decide whether a change is substantial. For systems that continue to learn after market placement, changes pre-determined at the initial assessment and documented under Annex IV point 2(f) are not substantial modifications (Article 43(4)).

Three pipeline stages that fit these duties (our suggestion)

The Act names no pipeline stages. This split puts fast checks on every pull request and the full scan before release.

Stage 1: pull request checks

Run on every pull request to give developers fast feedback.

  • Code scan: Rule-based static analysis flags AI components and missing patterns, for example AI operations without logging. It detects standard ML framework patterns only.
  • Document check: Policy rules check that required documents exist and contain the required sections. They check that content is present, not that it is true or good.
  • Risk class record: Check that the system’s risk classification is recorded and reviewed when the code or the intended purpose changes. The classification itself is a human decision (Article 6).

Stage 2: merge gate

A check before merge that can stop non-conforming changes.

  • Finding limits: Set limits for critical and high findings. In blocking mode, a scan above the limits fails the check.
  • Article 5 and Article 14 findings: A code scan cannot show intent or context. A human reviews every finding that points to a banned practice (Article 5) or to missing human oversight (Article 14).
  • Documentation changes: Check that the Annex IV documentation changes in the same pull request as the code it describes.

Stage 3: pre-release scan

A full scan of the release candidate.

  • Full scan: A complete code and document scan. Document scanning supports eight languages: EN, DE, FR, IT, ES, NL, PL and PT.
  • Dossier draft: Scanara drafts documents aligned with Annex IV and Annex V from your inputs and assessment answers. Autofill is partial; you write and verify the rest.
  • Evidence snapshot: Keep the scan report with the release record, so that you can show what was checked and when.

How Scanara’s GitHub merge gate works

Scanara receives GitHub pull request events, scans the change and reports the result as a GitHub check run. In report-only mode a failed check is reported as neutral. In blocking mode the check fails.

The merge gate works with GitHub only. Scheduled scans are not available yet; scans run on demand and for pull requests.

What the scans check, and where they stop

Coverage is partial. In the snapshot of 24 August 2026, 77 of 174 mapped obligations have code rules, across 43 articles, and 23 have document rules, across 23 articles. The mapping predates the Omnibus changes of Regulation (EU) 2026/1744, for example Articles 4a, 60a and 75a to 75d. The other obligations need assessments and human work.

Code rules

  • Article 5: prohibited practices

    Rules flag code patterns that can indicate a banned practice. Whether a practice is banned depends on purpose and context, which code does not show.

  • Article 9: risk management

    Rules flag AI decision points without recognisable risk assessment or validation code.

  • Article 10: data governance

    Rules flag training pipelines without recognisable data quality checks.

  • Article 12: record-keeping

    Rules flag AI operations without recognisable logging.

  • Article 14: human oversight

    Rules flag decision paths without a recognisable human intervention point, such as an override or a stop procedure.

  • Article 15: accuracy and robustness

    Rules flag missing model validation and missing accuracy metrics.

Document rules

  • Technical documentation sections (Article 11)

    Scanara’s rules define eight required sections for technical documentation, based on Annex IV, and check that they are present. They check that content is present, not that it is good.

  • Instructions for use (Article 13)

    Checks that the instructions for use exist and contain the required sections.

  • EU declaration of conformity

    Checks that the declaration contains the elements listed in Annex V.

  • Eight languages

    Document scanning supports EN, DE, FR, IT, ES, NL, PL and PT.

Implementation checklist

  • Add a code and document scan to the pull request workflow.
  • Start in report-only mode and review the findings.
  • Set limits for critical and high findings, then switch to blocking mode.
  • Require human review of every finding that touches Article 5 or Article 14.
  • Keep the scan report with each release record.
  • Flag changes to the model, the training data or the intended purpose for review as possible substantial modifications (Article 43(4)).
  • Re-run the full scan before each release and update the Annex IV documentation.
  • Keep the technical documentation in the repository next to the code and update it in the same pull request.

Exclusions, older systems and fine caps

The Regulation does not apply to AI systems used exclusively for military, defence or national security purposes (Article 2(3)). It does not apply to AI systems specifically developed and put into service for the sole purpose of scientific research and development (Article 2(6)), or to research, testing or development before placing on the market or putting into service, except testing in real-world conditions (Article 2(8)). Free and open-source systems are excluded unless they are placed on the market or put into service as high-risk systems or fall under Article 5 or 50 (Article 2(12)). Natural persons who use a system in a purely personal non-professional activity are not bound as deployers (Article 2(10)). For high-risk systems related to products under Annex I Section B legislation, such as motor vehicles, aviation, rail, marine equipment, agricultural vehicles and machinery, only Article 6(1), Article 60a and Articles 102 to 112 apply. Articles 57 to 59 apply only in so far as that legislation integrates the requirements (Article 2(2)).

High-risk systems placed on the market or put into service before the application date are covered only after significant design changes. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)).

For SMEs, each fine is up to the percentage or amount, whichever is lower (Article 99(6)). For small mid-cap enterprises (SMCs, defined in Article 3(14b)), the same cap applies to fines under Article 99(4) and (5) (Article 99(6a)). The EUR 15 million tier also covers the obligations of providers and operators under Article 25(2) and (4) (Article 99(4), point (da)).

Read next: audit trails, rule-based scanning and technical documentation

Scanara prepares evidence from your repositories

Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.