How should teams monitor and audit AI-enabled engineering?

Code history shows what changed, but AI-enabled delivery creates additional questions. What goal was the system given? Which data and tools could it reach? What checks ran? Where did a person intervene? Did the resulting change behave as expected after release?

Monitoring answers urgent operational questions, while auditability preserves enough connected evidence to reconstruct a decision later. Both should be designed before broad agent use, because missing context is difficult to recreate after an incident.

Define the questions the evidence must answer

Start with concrete uses: detecting unsafe behaviour, diagnosing a failed change, confirming an approval, investigating data exposure, comparing a trial with normal delivery or improving a control. These purposes determine what must be recorded and who needs access.

For material workflows, retain identifiers that connect the task, user or agent identity, model or service where relevant, permitted tools, important actions, changed artefacts, automated checks, approvals, deployment and operational result. Record policy exceptions, denied actions, retries, cancellations and recovery. Timestamps and version information help show which instructions and controls applied.

Do not confuse comprehensive evidence with recording every possible token forever. Minimise collection according to the purpose, sensitivity, cost and retention requirement. Document known gaps so reviewers understand what the record can and cannot establish.

Observe the workflow and its control boundaries

Monitor whether the agent stays within its intended repository, environment, tools, network destinations, time and cost limits. Alert on attempts to reach sensitive data, use unapproved tools, change protective controls, conceal activity or repeat failed actions. Track when humans broaden scope, override a safeguard or approve an exception.

Quality signals should include review findings, failed tests, security or dependency findings, rejected changes, rework and abandoned tasks. Activity counts such as prompts, generated lines or agent runs say little about value on their own and can reward undesirable behaviour.

NCSC guidance for secure AI systems recommends monitoring system behaviour and inputs to support investigation and remediation, while respecting privacy and data protection requirements. For engineering agents, the same principle extends to tool calls, environmental effects and control decisions.

Connect delivery evidence to production outcomes

Successful generation, review and deployment do not prove that a change delivered the intended outcome. Link AI-enabled changes to the same operational signals used for other software: reliability, errors, latency, security events, customer effects, rollback, support demand and maintainability. Choose signals relevant to the product and its risks.

Preserve provenance at a useful level so an incident team can identify affected changes and reconstruct their route to production. Avoid treating AI authorship as the cause before investigation. Human-written and AI-generated changes can fail; the relevant question is which assumptions, controls or decisions allowed the failure to escape.

For an experiment, compare end-to-end results including supervision, review and recovery effort. A faster coding step may shift work downstream. Monitoring should reveal that movement rather than celebrate local output.

Turn audit findings into better controls

Define who reviews routine evidence, which events trigger immediate response and how a workflow can be stopped. Exercise incident and recovery procedures before relying on an agent for consequential work. Confirm that teams can revoke access, preserve evidence, restore state and communicate ownership.

Review trends across incidents, near misses, denied actions and manual interventions. Improve task boundaries, repository context, permissions, tests, approval points or training according to what the evidence shows. Assign owners and due dates to material findings.

Audit records contain attractive information: source code, prompts, system structure, identities, vulnerabilities and possibly customer data. Restrict access, protect integrity and set deliberate retention. Auditability is successful when it enables accountable decisions and safer delivery, not when the organisation simply accumulates a larger volume of logs.

Example

An agent prepares a change to a customer onboarding service. Its run record links the approved task, scoped identity, tool calls, commit, automated checks and engineer approval. Deployment metadata carries the same change identifier into operational monitoring.

After release, an error-rate alert identifies the affected version. The team can see the agent's assumption, the generated test, the review decision and the rollback. The finding is not recorded as “AI made an error”. It shows that the acceptance evidence missed an existing integration condition, leading the team to improve its test environment and approval summary.

FAQs

• Should teams store every AI prompt and response?

  Not automatically. Retain the evidence needed for defined operational and audit purposes, while minimising sensitive data and applying suitable access and retention controls.

• What is the difference between monitoring and auditing?

  Monitoring helps detect and respond to current behaviour. Auditing reconstructs activity, evidence and decisions over time. The same records may support both, but their users and retention needs can differ.

• Should AI-generated lines of code be a productivity measure?

  No. Generated volume does not show customer value, quality or saved effort and can encourage unnecessary code. Measure end-to-end delivery, human effort, technical health and product outcomes instead.