Welcome
This tier is for the person who owns a reporting or analytics function — a BI lead, senior analyst, or small-business owner — and needs to stand up an AI-augmented capability that security and governance will actually sign off on. By the end you'll be designed to have a reference architecture and a governance checklist you can put in front of your own stakeholders.
This is the only tier that assumes some technical comfort. It still holds the line from Tiers 1 and 2: check the answer, protect the data, and never let the model produce the number.
Module 1 — Agent and workflow orchestration
The idea. A single prompt is a tool; a workflow is a system. Orchestration is chaining steps — some AI, some deterministic — so that a request flows through a reliable sequence rather than relying on one model to do everything.
The design principle. Give each step the narrowest possible job. An AI step that "reads a request and decides what's being asked" is doing one thing. A deterministic step that "runs that query against the data" is doing another. Don't let one step both decide and compute and present — that's where errors hide.
Multi-step patterns. Typical chain: interpret the request → fetch or compute the answer deterministically → check the result against rules → narrate it. Each handoff is a place you can inspect, log, and test. The more inspectable the seams, the more trustworthy the whole.
Governance angle. Orchestration is also where accountability lives. If you can point to which step produced which output, you can audit it. A black-box "the AI did it all" is unauditable — and unauditable is unsignable for most security teams.
Reflect. Sketch one workflow you'd want to build as a chain of narrow steps. Mark which steps are AI (interpret, narrate) and which must be deterministic (compute, decide-by-rule).
Narrow steps, inspectable seams, deterministic where it counts. Auditable beats clever.
Module 2 — Private RAG and on-device AI for sensitive data
The idea. Two techniques let you use AI on data you can't send to the cloud. RAG (retrieval-augmented generation) grounds the AI in your documents — it retrieves relevant passages and answers from them, instead of from its general training. On-device / small language models (SLMs) run the model locally, so the data never leaves your environment at all.
Why this is the unoccupied position. Most AI products send your data to someone else's servers. For organisations with sensitive operational data — and no corporate legal team to absorb a leak — that's a non-starter. Private, grounded, on-device AI is precisely the gap, and it's where a security-conscious team can adopt AI without flinching.
Practical shape. A private RAG setup keeps your documents in a local index; the model retrieves from it and cites which passages it used. An on-device SLM (run via a local runtime) handles the language work without any outbound call. Combine them and you have an assistant that is grounded in your material and never phones home.
The honest limits. Smaller, local models are less capable than the largest cloud ones — you trade some raw ability for privacy and control. For grounded, narrow tasks that trade is usually worth it; for open-ended reasoning it may not be. Choose deliberately.
Reflect. Identify one task in your organisation that's currently not done with AI purely because the data can't leave. That's a candidate for private/on-device.
RAG grounds in your data; on-device keeps it home. Trade some capability for privacy and control. This is the security-conscious team's way in.
Module 3 — Synthetic data done right
> Please note: this module is general education, not legal or privacy advice. De-identification and anonymisation obligations vary by jurisdiction — confirm yours with a qualified adviser.
The idea. Tier 2 taught you to make synthetic data. This module is about doing it correctly at scale, and knowing what it does and doesn't buy you.
Re-identification is the real risk. Removing names is not anonymising. Combinations of "quasi-identifiers" — a date, a postcode, an unusual amount — can single out a record even with names gone. Good synthetic generation mirrors distributions and breaks those links; it does not just blank out columns.
Fidelity vs privacy is a dial. The more faithfully synthetic data mirrors the original, the more useful it is — and the closer it edges toward revealing real patterns. Techniques like proper holdout, distance checks against real rows, and differential privacy let you tune where you sit on that dial deliberately, rather than by accident.
"Still personal data." In many regimes, de-identified data that could be re-identified is still treated as personal data. So synthetic data is a powerful risk-reduction tool, not a "now it's exempt" button. Reduce, not remove — the same line we hold throughout.
Verification. Never ship synthetic data without checking it: confirm no real row is reproduced, measure how well it matches, and flag risky unique combinations. (Our Sandbox tool models this — a leakage check and a fidelity report on every run.)
Reflect. For one dataset, list which columns are quasi-identifiers (not just the obvious names). Those are the ones that need the most care.
Un-naming isn't anonymising. Fidelity and privacy trade off — tune deliberately. De-identified can still be personal data. Always verify.
Module 4 — Deterministic vs generative architecture (the Parkvara pattern)
The idea. This is the architectural heart of trustworthy AI tools, and it generalises the number rule into a full pattern: English → query-intent → deterministic engine → source-cited answer → AI narration.
Walking the pattern.
- 1. The user asks in plain English.
- 2. An AI step translates that into a structured request — a precise statement of what's being asked. It stops there; it doesn't answer.
- 3. A deterministic engine executes that request against the real data and returns the exact result, with the source rows it used.
- 4. The AI narrates the result in words — describing, never recomputing.
Why it's the differentiator. Every number is traceable to its source, and the model is structurally prevented from inventing figures. You can hand the output to a finance lead and point at where it came from. Competitors who let the model "just answer" can't make that promise — and that promise is exactly what a trust-anxious buyer needs.
Designing for it. Build the seams explicitly: the structured request is inspectable, the engine's output is cited, the narration is clearly separate from the computation. When something looks wrong, you can tell which step to fix.
Reflect. Take one analytics question your team answers with AI. Map it onto the four steps. Where does the number actually come from today — and is it the engine, or the model?
Interpret → compute deterministically → cite → narrate. Traceable by design. Structurally can't hallucinate a figure. This is the pattern to standardise on.
Module 5 — AI governance, risk, and the boundaries that matter
> Please note: general education, not legal advice. Apply your own jurisdiction's rules and seek qualified counsel for specifics.
The idea. A capability without governance won't survive contact with a security review. This module is the checklist that lets you put AI in front of stakeholders with confidence.
A practical governance checklist:
- Accuracy controls — where does each number come from, and how is it verified? (The deterministic pattern is your answer.)
- Data boundaries — what data can the system touch, where does it go, and what never leaves? Document it.
- Quality gates — what's checked before output is trusted or published, and who signs off?
- Auditability — can you trace any output back to its inputs and the step that produced it?
- Human accountability — who is responsible for the system's outputs? (Always a person, never "the AI.")
The boundaries that matter most.
- Data / privacy — sensitive data handling, de-identification limits, and the reduce-not-remove reality.
- Ownership / IP — work and data created in an employment context typically belong to the employer; anonymising or synthesising doesn't transfer ownership. Keep employer and personal projects cleanly separated.
- Honesty in claims — edge, not guarantee: describe what the system reduces and improves, never promise certainty or compliance you can't back.
The mindset. Governance isn't the brake on AI adoption — it's what makes adoption durable. The teams that move fastest in the long run are the ones whose AI a security team already trusts.
Reflect. Run one AI use you're considering through the five-point checklist. Wherever you can't answer cleanly, that's the work before it ships.
Accuracy, data boundaries, quality gates, auditability, accountability. Respect the data, ownership, and honesty boundaries. Governance is what makes AI durable, not slower.
Close
Across three tiers you've moved from "what AI is and how to use it safely," through "building real, data-safe tools," to "designing and governing an AI-augmented capability." The throughline never changed: check the answer, protect the data, and never let the model produce the number.
This material reduces risk; it doesn't remove it. Edge, not guarantee.