Auditing an AI System Someone Else Built: What We Check in a RAG or LLM Feature

Sooner or later most companies that shipped an AI feature ask the same question: is the thing we have actually good? Someone else built it (a vendor, a freelancer, a team that has moved on), it works in the demo, and nobody can say how often it is wrong, what it costs per answer or what happens when the model provider ships an update.

Short answer. To audit an existing AI system (an LLM or RAG feature someone else built), you review five things: security, robustness (is correctness measured, not demonstrated), technology choices, automation and cost per answer. At 4xxi it runs inside our AI opportunity audit: 2 weeks, $5–10k fixed, full money-back guarantee, and the fee is credited toward any project signed within 60 days. You get a prioritised fix list with hour estimates at $200/h.

What is an AI system audit, and what does it cost?

An AI system audit (often called an LLM or RAG audit) is an engineering review of an AI feature that is already built: the code, the prompts, the retrieval pipeline, the infrastructure and the numbers behind it. The question it answers is plain: can the business rely on this system, and what does it take to make it reliable?

With us it costs $5–10k and takes 2 weeks. For a sense of the market, a June 2026 pricing guide from the security firm SecurityWall puts a security-focused LLM audit or AI red-teaming engagement at $6,000 to $45,000 or more, and at $40,000 to $150,000+ with the Big Four consultancies (SecurityWall, checked 2026-10-29). I compare our other prices with UK and US market rates in how much AI development costs.

Where a given audit falls in that range depends on scope: one chatbot over a single document collection is a smaller job than a platform with several models, agents and integrations. The audit is fixed-price, money-back if it is not useful, and credited in full toward a project signed within 60 days. Fixes, new features and ongoing work after the audit are billed hourly, at the same $200/h rate we use for development, consulting and fractional CTO work.

Who does it? The same senior engineers who build our own systems, with 15–20 years each in software, and myself. I have a PhD in astronomy and publish on LLM evaluation in peer-reviewed journals, and the habit I bring from research is simple: measure before you claim. An audit is exactly that habit applied to someone else’s code.

Is it the same as an ISO 42001 or EU AI Act audit?

No. A technical audit asks whether the system works; a governance audit asks whether the organisation manages AI responsibly. Both are useful, but they are different jobs done by different people.

Mökander et al. describe a three-layered approach to auditing large language models: governance audits of the provider, model audits, and application audits. Our audit lives almost entirely in the third layer, the application your users touch.

	Technical audit (what we do)	Governance audit
Main question	Is the system correct, secure and affordable?	Are AI risks managed by the organisation?
Reference	Your code, data, logs; OWASP Top 10 for LLM Applications 2025	ISO/IEC 42001:2023, EU AI Act (Regulation 2024/1689)
Who does it	Engineers who build such systems	Certification bodies, compliance consultants, lawyers
Output	Fix list with effort estimates	Gap analysis, policies, certificate
Typical cost	$5–10k (our audit)	$15,000–60,000 in total (preparation plus certification audits) for most small and mid-sized organisations seeking ISO 42001, according to CertPro (checked 2026-10-28)

In practice, they feed each other. A governance auditor will ask how you test the system and how you control model changes, and a technical audit gives you real answers to those questions. However, if what you need is a certificate or a legal opinion on EU AI Act conformity, we are not the right people.

How do you audit an existing RAG or LLM system?

An audit of a RAG or LLM system checks five areas: security, robustness, technology choices, automation and cost. Inside robustness we go down to the level of a single answer, and the checklist below is what we go through on a RAG or LLM feature.

Area	What we check
Security	Prompt injection paths, sensitive data in prompts and logs, system prompt leakage, whether retrieval respects user permissions, where API keys live, rate limits and spend limits
Evals	Is there a test set of real questions? Who wrote it? Does it run before every release, or only once before launch?
Retrieval	Do the right passages come back, and is retrieval measured separately from answer quality? How are documents split (tables, footnotes, headings)? Is there reranking?
Citations	Does every claim point to a source, and does the source actually say it? (more on citation checks)
Refusals	What does the system do when the documents have no answer: say so, or guess?
Cost per answer	Tokens per request, context size, model choice, caching; what one answer costs now and at 10 times the traffic
Version pinning	Are model versions and prompts pinned and versioned, or does a provider update silently change behaviour?
Regression risk	If someone changes a prompt tomorrow, what tells you something broke?
Traceability	Is every answer logged with the question, the IDs of the retrieved passages and the prompt and model versions, so a wrong answer can be traced to its cause?
Technology choices	Is the model right for the task? Is the stack proportional to the problem?
Automation	CI, tests, deploys, dependency updates, secret scanning

Technology choices deserve a comment. Teams often pick the most expensive commercial model by default, or, on the contrary, a small local model to save money, without measuring either. In our peer-reviewed benchmark (Smirnov & Carruba, Scientific Reports, 2026), commercial models reached up to 94% F1 on the three-class set and the best open-source models 76%, while on simple, unambiguous cases both reached 100%. In other words, the answer depends on the task, and one has to measure it on your data. I wrote more about it in commercial vs open-source LLMs.

What do we usually find?

The problems we find most often sit in three places: security and architecture, a ‘zoo’ of stacks, and automation that is available for free and not used. These patterns repeat across audits of systems built by different teams.

Security and architecture. AI features are often added quickly, on top of an existing product, and the security model of the product does not reach the new feature. Typical questions we raise: can a user get a document into the model’s context that she is not allowed to see? Can a crafted question or a crafted document change the system’s instructions (OWASP calls it prompt injection, LLM01)? Is there anything that stops one user from burning the monthly model budget in an evening (unbounded consumption, LLM10)? Architecture issues go together with this: the model is called from several places, each with its own prompt and its own error handling, so nobody can say how the system behaves as a whole.

A ‘zoo’ of stacks. A typical picture: retrieval is written in one language, the backend in another, some logic lives in a no-code workflow tool, and embeddings sit in more than one store. Each piece was a reasonable decision at the moment it was made. Together they make every change expensive, because one feature touches four technologies and nobody knows all of them.

Automation that nobody turned on. This one is almost painful to see, because it costs nothing. GitHub alone gives you Actions for tests and deploys, Dependabot for dependency updates and secret scanning for keys committed by mistake. In the systems we audit, some of these are often not configured, so deploys are manual, dependencies drift, and a release depends on one person who remembers the steps.

Why does our chatbot work in demos but fail in production?

Because a demo tests the questions the builder chose, and production tests the questions your users ask. The gap between the two is where most failures live.

The usual causes, in the order I would check them:

1. No eval set from real traffic. The system was tuned on a handful of questions. Real users phrase things differently, ask about edge cases and mix topics.
2. Retrieval tuned on a few documents. It worked on ten clean PDFs and breaks on scanned tables, long annexes or documents with similar wording. Our RAG implementation guide covers how to get this part right.
3. No refusal path. When the documents have no answer, the model writes a plausible one. This is the classic hallucination, and a prompt that says ‘do not invent’ does not fix it reliably. Grounding has to be enforced in code (see how to build a chatbot that does not hallucinate).
4. Unpinned versions. The provider updated the model, or someone edited a prompt, and nothing measured the effect.
5. Cost that grows with usage. Long contexts and repeated calls are invisible at demo scale and very visible on the invoice.

A wrong answer in production is also a liability, not only an embarrassment. In Moffatt v. Air Canada (2024 BCCRT 149), the Civil Resolution Tribunal of British Columbia held the airline liable for wrong bereavement-fare information that its website chatbot gave a customer, and rejected the argument that the chatbot was responsible for its own words (the decision on CanLII).

What do we usually recommend?

Most of our recommendations move reliability from the prompt into the code and make quality something you measure. On top of that, we suggest which features to add, which flow gives better results and which robust methods to use; the exact list depends on the system.

Here is what that looks like in our own product, Edtek Chat, which we use as a reference point in recommendations:

• citation numbers are assigned by the retrieval step, not written by the model;
• any reference to a passage that was not retrieved is removed before the answer is shown;
• if nothing in the selected sources matches a first question, the model is not called at all, and the reader is told the library has no answer;
• answers built on weaker matches are labelled as such;
• an optional second model filters passages before answering and reviews the draft against its citations afterwards;
• an evaluation suite runs golden questions through the same pipeline that serves readers, with an LLM judge, retrieval assertions, confidence checks and latency budgets, and compares each run against a baseline to catch regressions.

Not every system needs all of it. However, almost every system needs the last item. Deterministic checks (scores, rules, assertions) plus an LLM judge, a baseline and a regression set are what turns ‘it seems fine’ into a number. I described the method in more detail in scientific rigour in AI development.

The American Arbitration Association’s AAAi Chat Book series is built with the same product; its first edition launched in January 2025. I mention it because the recommendations come from systems we run ourselves.

A wrong answer should be caught by the system, not by your customer. If the only thing between the model and the user is a sentence in the prompt, the system is not finished.

What do you get at the end of the audit?

You get a prioritised fix list: each problem with its risk, the recommended fix and an estimate in hours. Since our hourly rate is the same $200/h for all work, the estimate converts directly into money (for example, a 10-hour fix is $2,000), and you can decide what to do in-house and what to give to us.

The report is ordered by risk, not by convenience:

1. Fix now. Security issues and anything that can leak data or run up costs without a limit.
2. Fix before the next release. Missing evals, unpinned versions, no refusal path.
3. Fix when you touch it. Stack consolidation, automation, refactoring.
4. Consider. Features and flow changes that would improve results.

Everything we produce is yours: the code we write, the prompts and the eval sets belong to the client. If your own team takes the list and does the work, that is a perfectly good outcome. If you want us to work next to them, we do it inside your codebase and processes (see working alongside your in-house team).

Our AI vendor left. Can you rescue a stalled AI project?

Yes. An AI project rescue starts the same way as an audit: understand what exists before changing anything. Usually a stalled project is not hopeless. Nobody can deploy, test or explain it anymore, and these are exactly the things to restore first.

The order we follow:

1. Get access and secure it. Repository, cloud accounts, model provider keys, domains. Rotate keys that the previous team had.
2. Make it deployable. If the system cannot be rebuilt from the repository by a pipeline, nothing else is safe to do.
3. Measure the baseline. Build a small eval set and record how the system performs today, before anyone ‘improves’ it.
4. Decide: fix, rebuild or retire. Sometimes the core is fine and the problems are around it. Sometimes the cheapest path is to keep the data and rebuild the pipeline. And sometimes the honest answer is to switch the feature off, because nobody uses it or it does not pay for itself.

Not every rescue is a big project. We have had engagements of a few days where the job was simply to deploy what was already written, properly, with automation, so the client could move on. If you are integrating AI into a product you already run, this guide on integrating LLMs into existing software is a good companion.

When don’t you need an audit?

You don’t need an audit if nobody relies on the system yet, if your team already measures it, or if what you need is a certificate. In these cases the money is better spent elsewhere.

• It is still a prototype with no users. Build an eval set from day one instead; it is cheaper than auditing later. Edtek’s protocol for evaluating a RAG chatbot is a good start: about thirty questions from your own documents, a third of which have no answer in them.
• Your team already has evals, CI and cost monitoring. Then you probably know your weak spots better than an external reviewer. A day of pair review might be enough.
• The problem is one obvious bug. Fix the bug. An audit is for when you do not know where the problems are.
• You need ISO 42001 certification or a legal opinion. Go to a certification body or a lawyer; we are neither.
• You have not built anything yet. Then the question is not ‘is it good’ but ‘is it worth building’, and that is the other half of the same AI opportunity audit.

If you are still deciding who should do this kind of work, see how to choose an AI development partner.

How do I start an audit of our AI system?

Start with a short description: what the system does, who built it, what stack it runs on and what worries you (wrong answers, cost, security, or simply that nobody understands it anymore). We will tell you within one call whether an audit makes sense and where it falls in the $5–10k range. To save time in the first days, have read access to the repository and the prompts ready, along with the model provider’s usage dashboard and a sample of real user questions from the logs. If you have a few questions where you know the right answer, bring those too.

Start the AI audit, choose ‘AI opportunity audit’ in the contact form, or book a call with me directly. Two weeks, fixed price, money-back if it is not useful, and the fee is credited toward any project signed within 60 days.