P0Critical, fix before production
AI tooling has overly broad data access
Backend retrieves customer context by ticket id without proving the support agent has rights to that specific record.
BLUEPRINT v1.0 · ExampleAI B.V., Support Assistant POC · SAMPLEPOC2Prod Blueprint™ · sample
What a Blueprint™ report actually looks like.
This is the anonymised exhibit I hand to a CTO at the end of the audit, a readiness score, every domain graded, findings ranked by severity, and a plain next step. The numbers below are the same ones shown on the homepage scorecard.
Production-readiness score
Hardening required before production
One headline score, then every domain graded out of five. Weakest domains are listed first, that is where the audit spends its evidence.
BLUEPRINT v1.0 · SAMPLEExampleAI B.V. · Support Assistant POC
5-10 day audit2.6/5READINESS
9 domains · 10 ranked findings · backlogNext step: AI Hardening Sprint™ →
Findings, ranked by severity
Top findings, ranked by severity
A full report ranks ten findings P0 to P3, each with evidence, an owner and acceptance criteria. This exhibit shows the top of that list. Each severity carries a written label, never a bare colour.
P0Critical, fix before production
Full prompts and outputs are logged
Application logs contain customer questions, names, e-mail addresses and ticket bodies, with no defined retention.
P1High, fix in hardening sprint
No rate-limiting on AI endpoints
Model-call endpoints have no per-user or per-tenant limits and no cost guardrails.
Anonymised excerpt. Real reports include 10 ranked findings, detailed evidence and acceptance criteria for each.
What this report would recommend next
The verdict is not “pass” or “fail”. It is a costed, sequenced path. For this sample, the base architecture is usable, so a targeted hardening sprint beats a rebuild.
Do not go live with real customer data yet
Two P0 findings: broad AI data access and full prompt/output logging, must be closed before real customers touch the system.
Run a 2-4 week AI Hardening Sprint™
Object-level authorisation, privacy-safe logging, central secrets management, rate limiting and a minimal incident runbook. This clears the P0s and the load-bearing P1s.
Then a limited production pilot can be justified
Once logging, monitoring and incident response are in place, a scoped pilot is defensible, with an evidence pack ready for the first client questionnaire.
Remediation roadmap
The same backlog, sequenced into three honest horizons.
First 7 days
- Rotate AI-provider and database secrets
- Stop full prompt and output logging
- Add an object-level authorisation check on customer context
- Tighten access to staging logs as an interim control
- Document the data flow and AI flow
First 30 days
- Implement privacy-safe logging with redaction and retention
- Add dependency and secret scanning to CI/CD
- Add rate limiting and cost guardrails to AI endpoints
- Build a minimal AI abuse test suite (prompt injection, leakage)
- Write a compact incident-response runbook
First 90 days
- Stand up a production-readiness dashboard
- Make an SBOM part of the release process
- Introduce periodic access review
- Refine the AI risk register
- Have legal counsel assess whether a DPIA is needed
Where this stops
The Blueprint™ is senior-engineer technical work. It is not a pentest, a DPIA or a legal opinion. Where one of those is required, I say so and point you to the right specialist: a certification auditor, legal counsel or a penetration tester.
Technical readiness support, not legal advice or a compliance guarantee.
Want this for your POC?
A 30-minute call confirms whether the Blueprint™ is the right next step, what scope is realistic, and what risks are likely already in your system.