Building It Is the Easy Part
A practitioner's companion to today — what happens to an AI system after the demo works, told from the builder's side of the Security Operations Centre.
Bil Arikan
Learning Experience Design · AI Enablement · Learning Performance Architecture
30 seconds
Who I am
- I work in Learning & Development and build AI tools at work — including an internal program for people learning to build with AI, not just use it.
- Before L&D : a telecom systems instructor and technologist. I came to AI through systems, not a CS degree.
- I build in the open and write it down — bil.arikan.ca.
Why I'm up here: you're spending two days learning to defend systems. I want to show you the other chair — what it's like to be the person building the thing that eventually lands in someone's SOC.
// THE BRIDGE
You're learning to defend.
Others build the things that need defending.
Every alert in your queue tomorrow is someone's production system — shipped by a builder, with decisions baked in long before the first log line. This is the story behind the evidence: the compliance, the architecture, and the threat modelling that should have happened before any of it reached you.
2 minutes
The thing I built
A real-time, multimodal, bidirectional in-app assistant. It watches your screen, listens to your question through your mic, and guides you through the product step by step — live, not a text box.
- Built on Google's Agent Development Kit (ADK) — a working proof-of-concept, not a slide.
- The point: text chat was the default AI interface in our product. This was a different shape of help entirely.
INPUTScreen + voice + docs
Your natural language, your live screen, and product documentation, fused in real time.
OUTPUTStep-by-step, spoken
Guidance that reacts to what you're actually doing — bidirectional streaming.
CODE
github.com/bilarikan/
live-streaming-agent-with-google-adk
The real work
It worked — then I documented
Once the prototype ran, the next stretch wasn't more code. It was research — building accurate, first-pass documentation of how the system handles data, what it touches, and where the risk sits, so reviewers had something real to assess.
- Solution design & architecture — every component and data path, written down.
- Economic model — what it costs and what it saves, so the business case is real.
- InfoSec & data handling — a first-pass threat surface, before InfoSec asked for one.
- Legal, IP & procurement — touchpoints flagged early, not discovered late.
Done to real technical accuracy, the documentation changes the conversation from "you haven't thought about this" to "here's my read — where am I wrong?" It's also what reviewers, and eventually a SOC, lean on to trust the system.
TakeawayThe model was the easy part. The defensible artefact was the deep, accurate compliance and governance research — produced before anyone demanded it.
3 minutes
The layer no one shows you
Getting an AI prototype into production inside a real org means clearing two stacks of work that have nothing to do with the model.
COMPLIANCE GATES
- Procurement — what are you actually buying, and from whom?
- DPIA — Data Protection Impact Assessment.
- Information Security — the review you'll be on the other side of.
- Legal & IP — who owns the output, the data, the model?
- AI Assurance — can we stand behind how it behaves?
ARCHITECTURE REVIEW
- Composition — every component, every dependency.
- Data at rest — where it's stored.
- Data in transit — how it moves.
- Data being processed — where the model actually sees it.
- Systems used — the full map of what touches what.
The connective tissue
Your SOC training is the builder's threat model
The same instinct you're building this week — follow the evidence, model the attacker — has a name on the builder side: the OWASP Top 10 for Agentic Applications (the 2026 ASI list). It assumes an agent that plans, decides, and acts, not just one that emits text.
| ASI | Risk | Weight |
|---|
| ASI05 | Unexpected Code Execution (RCE) | High |
| ASI02 | Tool Misuse & Exploitation | High |
| ASI01 | Agent Goal Hijack | High |
| ASI03 | Identity & Privilege Abuse | Medium |
| ASI04 | Agentic Supply Chain | Medium |
| ASI06–10 | Memory poisoning · insecure inter-agent comms · cascading failures · trust exploitation · rogue agents | Watch |
Worked example · 1 of 2
The in-app assistant, under review
Trace the data. Every leg of the assistant's path is a question a reviewer — and one day a SOC — has to answer.
① Capture · screen + mic audio
▼
② In transit · streamed to the model
▼
③ In processing · the model infers
▼
④ At rest · transcripts & logs
▼
⑤ Action · it guides & acts in-app
- ① PII or customer data on screen? Consent to capture? → DPIA
- ② Encrypted? Which region does it egress to? → InfoSec + Procurement
- ③ Does the provider retain or train on it? Logged? → Legal/IP + AI Assurance
- ④ Stored where, how long, readable by whom? → Data Protection
- ⑤ What can the agent actually do? How scoped? → ASI02 · ASI03
For defendersThis is the analysis that should sit behind every AI feature before it ships. Investigating one means checking whether this work was actually done.
Worked example · 2 of 2
"An allowlisted message is a shell command."
My home AI lab: an agent that takes a message from my phone and runs it as bash on a GPU box. Useful — and a textbook ASI05 by design. So I threat-modelled my own build the way you'll model an incident.
# the honest finding
Everything on one flat /24.
Agent · inference · my personal files ·
every phone + IoT device — same LAN.
# blast radius = the whole house
Segment the network — agent can't reach home
▼
Default-deny egress — it can't phone home
▼
Data hygiene — nothing personal to steal
▼
Gate the powerful tool — human in the loop
The road to production
It earns trust one gate at a time
A prototype doesn't jump to production. It moves through stages — and at each one the compliance and security analysis goes deeper and the blast radius gets more controlled.
Stage 1Concept
A demo and a hypothesis. Light-touch: is the capability even worth real work?
Stage 2Prototype
Architecture and data-flow documented; a first-pass threat surface and DPIA screening.
Stage 3Pilot
Full DPIA, InfoSec review, legal touchpoints. Real data, limited users, monitoring on.
Stage 4Go-to-market
AI Assurance sign-off, IP & procurement closed, production monitoring and incident response.
For defendersBy the time a system reaches your SOC, it should have cleared every one of these gates. Part of defending it is knowing which gate it skipped.
2 minutes
What this means for your career path
Anyone can build a demo now. The value — and the jobs — sit in the gaps between three very different verbs.
Build it
Cheap and fast in 2026. AI made the demo the easy part. Necessary, not sufficient.
Ship it
Compliance, architecture, InfoSec sign-off. The work that turns a demo into production.
Keep it safe
Monitoring, threat-modelling, incident response — exactly the SOC skill you're building now.
For youTwo kinds of environment hire for this: high-context / high-responsibility places that trust you to own outcomes, and high-documentation / high-systems places that need everything written down and reviewed. Cyber skills are the passport into the second — and the credibility to do the first.
One question to carry with you
"What would need to be true for this to run in production —
and stay safe once it's there?"
Ask it of every demo you build and every system you defend. It moves the room from "is this done?" to "what's the path?" — and it's the same question whether you're in the builder's chair or the analyst's.
Take it with you
Resources & contact
Thank youYou're going to be good at defending these systems. I hope a few of you also build them — and remember that shipping it safely is the whole game.