Know when your AI feature gets worse
Test sets, regression checks and runtime controls for LLM features, so you know when quality drops and harmful inputs or outputs are caught.
Overview
LLM features change behaviour when you edit a prompt, switch a model or the provider updates one. Without tests, teams find regressions through complaints. Without runtime controls, a single crafted message can leak data or trigger the wrong action.
We build evaluation sets from your real traffic, run them on every change, and red-team the feature before release. At runtime we add PII redaction, prompt-injection defences, output filters and audit logs that record what the model saw and said.
Signs you need this
- Prompt changes go to production after someone tries a few examples by hand
- You cannot compare two models on your own use case with numbers you trust
- Customer personal data appears in prompts sent to an external model
- Nobody has tried to make your assistant ignore its instructions
What you get
- Evaluation sets
- Curated cases from real usage covering normal requests, edge cases and known failures, with expected behaviour for each.
- Regression pipeline
- Automated runs in CI that score each prompt or model change and block releases that fall below agreed thresholds.
- Red-team report
- Results of structured attempts at prompt injection, data extraction, jailbreaks and unsafe tool use, with fixes.
- Input and output guardrails
- PII detection and redaction before the model, and filters on outputs for leaked data, policy breaches and malformed responses.
- Audit logging
- Structured logs of inputs, retrieved context, outputs and guardrail decisions, stored with retention rules you set.
How the work runs
- 1
Baseline
1 to 2 weeks
We review the feature, sample real traffic and agree what good and bad behaviour look like.
- 2
Evaluation build
2 to 3 weeks
We assemble the test sets, choose scoring methods and wire the regression run into your pipeline.
- 3
Red-teaming
1 to 2 weeks
We attack the feature with injection, extraction and misuse cases and record every failure.
- 4
Guardrails and logging
2 to 3 weeks
We add runtime controls and audit logs, then re-run the red-team cases to confirm the fixes hold.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- A pull request that lowers evaluation scores below threshold fails CI
- Test messages containing personal data reach the model with those fields redacted
- Every red-team finding is either fixed and retested or recorded as an accepted risk
- An auditor can trace any single response back to its input, context and guardrail decisions
Tools we work with
- promptfoo
- Ragas
- DeepEval
- Langfuse
- Microsoft Presidio
- NeMo Guardrails
- Llama Guard
- GitHub Actions
- OpenTelemetry
- Python
Questions buyers ask
- Can you guarantee the model will never give a wrong answer?
- No one can. We measure how often it fails on cases that matter to you, catch regressions before release and limit the damage when something slips through.
- Will guardrails slow responses down?
- Slightly. Redaction and filtering usually add a small delay, and we measure it so you can decide which checks run on every request.
- Do audit logs create a new data protection problem?
- They can, so we redact before logging, keep logs in your region and set retention periods with your data protection lead.
- What access do you need?
- The feature's code repository, a staging environment and a sample of anonymised production traffic.
Talk to us about LLM evaluation and guardrails.
Tell us what you run and where. We reply within one business day with questions or a quote.