AI Engineering & Product: Charter

Software engineering ships code whose behaviour is defined. This function ships behaviour that is learned, which changes almost everything about how it must be built, tested and released. A regression here is not a failing test: it is a quiet drop in answer quality that nobody notices for three weeks.

It sits deliberately apart from Software Engineering. The disciplines share tooling and diverge on the thing that matters: what counts as correct.

The distinction this division exists to hold#

Using a chat assistant is not building an AI product. The gap between the two is most of the work, and it is where nearly every AI initiative stalls.

Using one gets you an answer. Building one means owning the evaluation set that proves the answer is still good next month, the guardrails that decide what the system refuses, the retrieval layer that grounds it in your data, the cost per outcome at scale, the fallback when the model is unavailable, the disclosure a regulator expects, and the person accountable when it is wrong.

This division builds products. It does not assemble demonstrations.

What it builds#

Model evaluation is listed as an area rather than a step because it is the one that makes the other eleven verifiable. Without it, every claim about a product's quality is a matter of opinion.

The products#

BvLogic operates its own AI products rather than only advising on them. That is the difference between a consultancy with a point of view and a company that has had to live with its own decisions.

ZeMe is the proof. It is not a demonstration built to be shown: it is a live product working on a real market, where a wrong answer costs somebody money and the feedback arrives whether or not anyone asked for it. Every discipline in this charter, held-out evaluation, drift watching, cost per outcome, an explicit autonomy boundary, exists in it because the alternative was found out.

That is the argument for taking this division seriously. Anyone can describe how AI products should be built. Rather fewer have had to keep one honest against a market that does not care what the model was trained to believe.

What this function owns#

The evaluation set. The company's most valuable AI asset, and the one most often treated as an afterthought. Without a held-out set that reflects real usage, "it seems better" is the only available verdict.

Guardrails. What the system refuses, what it escalates, what it will not say. Written as testable rules, not as intentions in a prompt.

Model and vendor selection, including the switching cost of each choice. A capability rented from one provider with no abstraction is a commercial position, not just a technical one.

Cost per inference and per outcome. An AI feature that delights users and loses money at scale is a product failure discovered late.

The autonomy boundary. For each feature, exactly what it may do without a human, and what it must hand over. This is the most important line the function draws.

What is NOT delegated to an agent#

• Moving the autonomy boundary. Widening what a system does unsupervised is a human decision, every time.
• Accepting an evaluation result that authorises a release.
• Approving a prompt or model change that reaches customers.
• Deciding what the system refuses to do. Refusals are policy, and policy is owned.

An agent can run the eval, summarise the diff and recommend. It does not sign the release.

KPIs#

AI agents in this function#

Evaluation agent. Runs the held-out set on every candidate change and reports the diff per category, not as a single score. A single score hides the category that collapsed.

Red-team agent. Attacks the system's own guardrails: prompt injection, goal hijacking, tool misuse, data exfiltration through outputs. Findings go to Security as well as here.

Cost-attribution agent. Tracks spend per feature and per outcome, and flags a feature whose unit economics have inverted. Read-only.

Drift-watch agent. Compares live output distributions against the last accepted release and raises a warning when they diverge, which is the earliest available signal of a silent regression.

These agents test and report. The release decision, the guardrail policy and the autonomy boundary stay with people, and the red-team agent's findings are never closed by the same agent that raised them.

SOPs#

• No release without an eval run against the current held-out set, with the diff attached.
• Eval-set hygiene. The set is versioned, and anything that leaks into training leaves it. A contaminated eval set is worse than none, because it reports confidence.
• Guardrail change protocol. Proposed, reviewed, tested against the red-team suite, then released; never edited live.
• Rollback rehearsal each release cycle, on the assumption the next change will need it.
• Incident path for AI-specific failures: wrong-but-confident output, refusal of a legitimate request, injection success, routed jointly with Security and Support.

Templates#

Test Plan, Architecture Diagram, QA Checklist, Release Checklist, model card, eval report.

Workflows#

In: product requirements from the product function, quality signals from Support, threat findings from Security, cost data from Finance, candidate capabilities from Research & Innovation.

Out: released features with their eval evidence, model cards, guardrail specifications, cost-per-outcome reporting.

Handoffs: Software Engineering for the surrounding application, QA for everything deterministic, Security for adversarial review, Legal for anything the system asserts to a customer.

The loop: eval → release → drift-watch → back to eval. A model shipped and left alone degrades against a world that keeps moving.

FAQ#

Why separate this from Software Engineering?#

Because correctness is defined differently. Deterministic software is right or wrong against a specification; a learned system is better or worse against a distribution. Mixing the two produces either untested AI features or an engineering team asked to certify something it cannot.

What is the most common failure?#

Shipping without a held-out evaluation set, then discovering a regression through customer complaints. The second most common is an eval set quietly contaminated by the data used to build the thing it is meant to judge.

How much autonomy should an AI feature have?#

Exactly as much as the cost of its worst plausible mistake allows. Write that boundary down per feature. Undocumented autonomy expands by accident.

Who is accountable when the model is wrong?#

This function, for the release. "The model decided" has never been an accepted answer to a customer, a regulator or a court, and the expectation is tightening rather than loosening.

What else is coming for AI Engineering & Product