The EU AI Act for engineering teams: scope, evidence and current dates

A practical guide to classifying an AI workflow, checking its evidence, and assigning responsibility.

Start with the workflow and the intended purpose

Using an AI model does not put every team under the same obligations. Begin with what the system does, whose decisions it influences, and whether your organisation develops it, supplies it, or uses it professionally.

A coding assistant used to draft a function and a system used to assess job applicants have different intended purposes. A project tool can also cross a significant boundary if its AI output is used to evaluate workers or allocate work based on personal characteristics. Product labels such as “assistant” or “project management” do not settle that classification.

Review both routes to high-risk classification: certain regulated products under Annex I and the uses listed in Annex III. Article 6 also contains conditions and exceptions that require analysis of the actual system. The Commission's high-risk classification guidance is a useful starting point, rather than a substitute for that assessment.

The application dates have changed

The AI Act entered into force on 1 August 2024. The AI Omnibus entered into force on 27 July 2026 and changed the implementation timetable. The earlier version of this article treated August 2026 as the Annex III deadline; that is no longer the current timetable. See the Commission's AI Omnibus notice.

The Commission's current implementation timeline distinguishes these milestones:

These dates are not a universal grace period. Check which provision and transition applies to the particular system. Existing contractual, data protection and sector-specific obligations also need their own assessment.

Separate useful activity records from legal evidence

For high-risk systems, Article 12 requires technical logging capabilities that support traceability appropriate to the intended purpose, risk detection and monitoring. It does not prescribe an identical checklist of fields for every AI workflow. The Commission's Article 12 reference explains the requirement and the additional provisions for certain biometric systems.

For an engineering team, the practical question is whether a reviewer can reconstruct a particular event. Start with a real run and inspect the available task reference, actor, authorised scope, tool calls, output and review decision. Record which fields are absent. A screenshot of an activity timeline proves neither complete coverage nor a successful export.

Test failure paths as well as successful runs. A cancelled action, an unavailable tool or a missing response should remain distinguishable from completed work. Avoid collecting sensitive prompts or unnecessary personal data merely to make a log more detailed.

Retention needs a separate check. Articles 19 and 26 address logs under the control of providers and deployers of high-risk systems. They specify a period appropriate to the intended purpose of at least six months, subject to applicable Union or national law. Verify the system's classification, the applicable date, who controls the records and the actual contractual retention before drawing a conclusion.

Give delegated work an explicit boundary

Suppose a team wants an agent to draft a release note. A useful operating specification names the source project, the documents it may consult, the output it should return and the person responsible for reviewing it.

That specification should then be checked against the implemented permissions. Read access to project work does not by itself require access to billing, staff records or external publication. A review step only protects the actions it actually covers; it should not be assumed to stop an independent tool outside the workflow.

Use a small reversible task to validate that boundary. Confirm both the permitted action and a representative action outside its scope. Keep the result with the deployment configuration so the next reviewer knows what was tested.

Transparency depends on the output and your role

Article 50 covers distinct obligations for direct interaction with people, synthetic-content marking, certain biometric or emotion-recognition uses, and disclosure of deepfakes or some public-interest text. The responsible party and exceptions differ by paragraph. A visible “AI” badge does not establish that all applicable requirements have been met. Consult the Commission's transparency guidance.

For example, an internal draft, a generated image exported to another platform and text published to inform the public can require different handling. Examine where content is produced, edited, exported and published. Check the relevant provider or deployer obligation, available machine-readable marking and applicable exceptions against Article 50.

What BIKLABS can demonstrate today

BIKLABS connects projects and work items with knowledge and developing AI capabilities. Its current product boundaries remain visible:

• Projects and work items: available for product demonstration, with lists, boards and detail views.
• Wiki and BIA — Preview: documentation and authorised assistance within the supported scope. Simultaneous editing remains in development.
• Internal agents — Alpha: configuration and available runs. Their presence does not establish reliable autonomous operation.
• External agents — Preview: the current MCP surface exposes nine tools across four project and work-item scopes. It is a limited interface.
• Gates — Pilot: visible requests and decisions for supported transitions. Coverage must be verified for the intended action.
• Runs, costs and activity — Preview: inspect the fields actually returned by the capability. Retention, exportability and audit coverage require separate verification.

These capabilities can help a team organise work and review available evidence. They do not certify a deployment or establish compliance on behalf of a customer. The AI Trust Center, security page and DPA explain the public scope and applicable documents.

A review your team can repeat

Before adopting an AI workflow, prepare a short record with the intended purpose, responsible owner, affected people, data sources and relevant third parties. Add the classification and legal questions that remain open.

Then exercise one representative workflow. Preserve the actual output, supported activity and review decision, with the configuration and date of the check. State what the test demonstrated and what remains unverified.

Finally, have the responsible people review the evidence and the contractual scope. Revisit the record when the intended purpose, permissions, provider, output channel or product behaviour changes. That creates a useful operational habit while the wider legal assessment proceeds.