Generative AI Applications

Effort goes to the use cases that can actually be built

Candidates are screened against tolerance for error, availability of the information, integration cost and measurable value before anything is engineered, and the list usually reorders.

A demonstration becomes something the business can depend on

Integration, evaluation, guardrails, monitoring and handover are treated as the substance of the work rather than as a phase appended to a prototype.

Capacity is released from routine language work

Drafting, summarising, classifying and extracting are automated where an error is survivable and catchable, with the person moved to reviewing and deciding.

Information held in text becomes reachable

Material locked in documents, tickets, correspondence and notes is summarised, searched and reasoned over instead of being read manually or ignored.

Output becomes consistent rather than dependent on who produced it

Prompting, structured output and approved source material are engineered as versioned assets, so the same task produces comparable results across teams.

Unsanctioned use is replaced by a governed route

Providing an approved application with defined data handling removes the reason staff were using consumer tools on business material.

Customer experience improves where response quality and speed matter

Drafts are produced from approved material and reviewed by a person, so responses are faster without surrendering control of what is said.

Business use case

Start from the task and its value: who does it now, how often, what a wrong output would cost and who would notice. Candidates are screened and ranked, and unsuitable ones are recorded as such.

Screened and ranked use-case portfolio

Feasibility

Establish whether the information the task needs is available and reachable, whether the tolerance for error can be met with a reviewer, and what the integration actually costs.

Feasibility position per candidate, with the reasons

Architecture and model

Design where the model sits, what grounds it, what it may not decide and where a person approves, then select the model by measuring candidates on the client's own task.

Solution architecture and model selection report

Build

Engineer the prompting, structured output, retrieval grounding, tool use and integration with the systems that supply the inputs and consume the outputs.

Working application inside the target workflow

Guardrails

Add input filtering, output validation, refusal and escalation behaviour, permitted and logged tool access, and the human approval points the consequences warrant.

Guardrail and oversight specification, implemented

Evaluate

Run the task-specific test set, measure against the agreed definition of good enough, and establish the regression suite that will run on every later change.

Measured baseline and regression suite

Deploy and monitor

Release into production with monitoring of quality, latency, cost per unit of work and failure, then hand over with a runbook and a named owner.

Monitored production application and handover

Which use cases are actually worth building?

The ones where the task is genuinely language-shaped, the information it needs is available, a wrong output is either survivable or catchable by a reviewer, and the volume is high enough to justify the engineering and the running cost. Screening happens before any build and it usually reorders the list the business arrived with. Some candidates fail because the information is not there, some because the surrounding process is broken in a way the model would amplify, and some because the tolerance for error is nil and no reviewer is available. ARRIX records the cases it recommends against, with the reason, because that judgement is part of what is being bought.

How do you choose which model to use?

By measuring candidates on your task with your data, rather than by general reputation or benchmark position. The comparison covers quality against a task-specific test set, latency, cost per unit of work, stability of output, and whether the available deployment options satisfy your data classification and residency obligations. Frequently a smaller and cheaper model is sufficient for a well-constrained task, with a larger one reserved for the steps that genuinely need it. The application is then built so that the model is a replaceable component, because the field moves and the choice will be revisited.

Can we trust the output? What about hallucination?

Not unconditionally, and any supplier who says otherwise is selling something. Language models produce plausible text, and plausible text is sometimes wrong, so the engineering response is to constrain the space in which that can happen: ground the task in retrieved organisational material wherever it depends on fact, require structured output validated against a schema, check outputs with deterministic rules and classifiers, keep a person approving anything with consequence, and measure failures against a test set rather than assuming their absence. That reduces ungrounded output, constrains where it can reach and makes it visible; it does not eliminate it. Use cases are selected on that basis, which is precisely why some proposals are recommended against.

We already have a working demonstration. Is that not most of the way there?

A demonstration proves the idea is possible on inputs someone chose. A system has to handle the inputs nobody chose, integrate with the systems that hold the information and receive the output, behave predictably when it is uncertain, keep a record of what it produced and why, cost a knowable amount per unit of work, and be operable by someone who did not build it. That gap is where most generative AI initiatives stop, and closing it is engineering rather than model work. What a demonstration usefully provides is evidence of appetite and a rough sense of the shape, not a head start on the parts that take the time.

How do you decide whether it is good enough?

Good enough is defined before the build, in the terms of the task: what the output must contain, what it must never contain, how it will be scored and what happens when it falls short. A test set is assembled from real examples with expected outcomes, and the system is run against it on every change to prompt, model, retrieval or tooling, so a regression is caught before release rather than by a user. Automated grading handles volume and human review handles judgement, because the two diverge exactly where the stakes are highest. Monitoring continues after deployment across quality, latency, cost and failure modes, because a provider's model can change beneath an application that was working yesterday.

Will this tie us to one provider?

It does not have to, and the architecture is built on that assumption. Model access sits behind an internal interface, prompts and evaluation sets are kept as your assets in your own version control, and retrieval, tooling and business logic live outside any single provider's framework. Changing model then becomes a measured re-run of the evaluation set rather than a rebuild of the application. ARRIX names candidate technologies so you can see what is proposed, and holds no partnership, reseller or authorised-representative relationship with any model provider.

Can we use this on confidential material?

That depends on a classification decision taken before any integration is built, not on an assurance offered afterwards. The question is which categories of your information may be sent to which class of model under which contractual and regulatory terms, and the answer differs between a hosted service, a private deployment inside your own tenancy and an in-region arrangement made for residency obligations. Once that is settled the application enforces it: what may be included in a prompt, what must be removed first, what is logged, for how long and who may read the logs. Where the requirement is that certain material never leaves your boundary, the design starts from that constraint rather than working back towards it.

What happens to the people currently doing this work?

In the designs ARRIX builds, the person usually moves from producing the first draft to reviewing and deciding, and that review is load-bearing rather than ceremonial. This is deliberate: removing the reviewer entirely is appropriate only where an error is cheap and easily detected, and most enterprise language tasks are neither. It also changes what the role needs, because judging output well is a different skill from producing it, so handover includes preparing the people who will carry that responsibility. Where a use case only pays if the reviewer is removed, that is far better known during screening than after deployment.