6 July 2026
A safe AI PoC in 30 days: a step-by-step implementation plan
A safe AI PoC in 30 days is a way to test one process on a real slice of data — without touching production, with limited data and budget exposure. You pick one process, inventory shadow AI, prepare a small dataset, build a proof it works on the slice, measure quality with evaluations, add guardrails and logs, and end with an informed go/no-go decision. This is an implementation post, not another AI Act explainer: it shows what gets produced on which day, who owns it, and which risk each step closes.
Why a PoC, instead of implementing straight away
A PoC (proof of concept) is the cheapest moment to learn whether AI will actually help in your process — before you spend the implementation budget. An AI readiness audit settles what is worth doing; the PoC proves it on one well-chosen slice and shows how it behaves on your data. Before day 1, classify the process’s risk — most AI Act obligations start to apply on 2 August 2026 — so the PoC is scoped with the right controls from the start, and a case unfit for a PoC is set aside deliberately.
The 30-day plan: what gets built, who owns it, which risk
This is a framework, not a fixed schedule — the scope of one process and the state of your data move the dates. “Owner” is a role on your side plus a consultant; a solo consultant does not replace your process owner or your IT.
| Days | Artifact | Owner | Risk it closes |
|---|---|---|---|
| 1–5 | Process pick + shadow-AI register | Process owner + consultant | Wrong case; data leaking through private tools |
| 6–10 | Data slice with permissions | Data owner + IT/security | Sensitive data, no processing basis, wrong source of truth |
| 11–20 | PoC on the slice + golden set | Consultant + process owner | ”It works” based on a hunch instead of a measurement |
| 21–25 | Evaluations + guardrails + logs | Consultant + IT | Hallucinations, no auditability, no operating limits |
| 26–30 | Unit cost + go/no-go decision | Board + IT + consultant | Going to production with no criteria and no cost |
Week 1: pick the process and audit shadow AI
Choose one repetitive process with a measurable effect and data you are allowed to use — handling enquiries, knowledge search, document work. In parallel, inventory shadow AI: the AI tools used outside IT’s knowledge. Without that register, neither data security nor compliance can be quantified. Do it as a concrete artifact, not a fear section — a simple table is enough:
| Tool | Who uses it | What data leaves | Decision |
|---|---|---|---|
| Public chatbot | Sales | Snippets of offers, client data | Replace with a company version / restrict |
| Note-taking plugin | Product team | Meeting notes | Check the terms, set a boundary |
| Private AI account | Individuals | Unknown | Inventory, cover with policy |
The scope of the three engagement levels — audit, implementation, retainer — is on the services page.
Week 2: data from a slice, not everything
A PoC on one tidy dataset tells you more than an index of everything at once. Take a small, representative slice: a few dozen to a few hundred documents that genuinely answer the questions from the chosen process. Check sources, permissions, quality and freshness — the full checklist is in data readiness for RAG. If the data is dirty on the slice, it will be dirty on the whole — better to know now. How we ground answers in your own documents with a citation is on the RAG / knowledge bases page.
Week 3: PoC, evaluations and guardrails
Only now do you build the proof it works — deliberately late, because without data and criteria a PoC means nothing. Assemble a golden set: real questions, expected answers and sources. Measure quality: retrieval relevance, answer groundedness in sources, citation correctness and hallucination control — we describe the five metrics and the method separately. Add guardrails (topic boundaries, sensitive-data filtering, a correct “I don’t know” refusal) and logs of every answer with its source. During the PoC keep the system read-only — agents that act inside your systems are a separate, later stage with their own oversight.
Week 4: logs, cost and the go/no-go decision
Compute the unit cost (the cost of one answer/operation) on real data, not from a price list. Then make the decision — and take it seriously. Go/no-go is a real decision, not a happy ending: a no-go is a cheap success, because it costs a fraction of a failed implementation. Write the kill criteria up front:
- evaluations below threshold (e.g. too many wrong citations or hallucinations),
- data too dirty to clean within a reasonable budget,
- unit cost higher than the value the process delivers.
We know this discipline — evaluations, guardrails and logs — survives contact with production, from our own system: in mojApteczka, extracting data from a drug package costs USD 0.0006 per scan at 100% accuracy on the validation set (n=200), and the production knowledge base holds 302,516 records. Those numbers didn’t come from a prompt — they came from the same discipline a PoC is meant to test (what GenAI really costs in production).
What a PoC does not settle
A successful PoC is proof that it’s worth implementing — not compliance itself, and not production. The risk class, documentation and oversight required by the AI Act can’t be replaced by a prototype; they are closed during the implementation. What the PoC gives you is the basis for an informed decision: you know what works, at what cost, and what’s still missing before production.
FAQ
Does an AI PoC have to use production data?
It doesn’t need full production — a small, representative slice of real data with the permissions reproduced is enough. Synthetic data can help at the start, but it won’t show true quality or risk; a real slice shows both with limited exposure.
How do you limit shadow AI?
Start with a register: tool, who uses it, what data leaves. Only with that picture do you decide — replace with a company version, restrict the data scope, or cover it with policy. Without the register a ban is cosmetic, and the data leaks anyway.
When should a PoC move to production?
When evaluations are repeatably above threshold, the unit cost is lower than the value of the process, and guardrails and logs work. If any condition is unmet, production is closing that condition — not scaling a doubtful PoC.
How do you measure RAG quality?
With five measures: retrieval relevance, answer groundedness in sources, citation correctness, hallucination control and a correct refusal. The basis is a golden set — we describe the method here.
Is a PoC enough for the AI Act?
No. A PoC can show that a system can be built to meet the requirements, but it does not replace the risk classification, documentation and oversight required by the AI Act — those obligations are closed during implementation.
What next
How we run the audit, the implementation and the upkeep — three engagement levels — is on the services page. Want to run this plan on your own process? Get in touch — we reply within one business day.