For the CIO / technical decision-maker
A department head wants to build with AI. You’re the one who answers for it.
You didn’t pick the project, but you’ll own the risk: the data it touches, the systems it plugs into, the environment it runs in, and the board question about what it returned. This page is how the engagement is built so each of those answers is one you’d give willingly.
Pilots that stall
You’ve seen the pilots that go nowhere.
Most AI efforts that reach your desk share a shape: a strong demo on curated data, then nothing in production. The numbers are brutal, and the share of companies abandoning their AI work is rising, not falling. The cause is rarely the model. It’s the translation layer you own: integration with systems of record, data at operational cadence, and the gap between “worked in a demo” and “runs on Tuesday.”
This engagement is designed backwards from that failure. Not a better demo, a workflow that reaches production because the hard parts, your systems and your sign-off, are the work rather than an afterthought.
The de-risk gate
Discovery exists so you decide with full information.
Nothing gets built until Phase 1, discovery and system design, is done. It ends with what you need to make the call: a written spec of what’s being built, how it plugs into your stack, what must be provisioned (a vector store, SSO, a data path), what needs buying, and where the human stays in the loop. Your engineer is in this phase, not just your functional stakeholders.
Then a sign-off, with a walk-away. If discovery surfaces a blocker in your environment, you find out before the build clock starts, with a written list of what would have to change. You’re never asked to greenlight a build you can’t see the shape of.
Phase 1 · Weeks 1 to 2
Discovery & design
- Map the workflow with your team and pick the single highest-ROI one worth building
- Scope it tight: a written spec, plus anything to buy or provision
Go / no-go
Either side can stop
Phase 2 · Weeks 3 to 6
Build
- Weeks 3 to 4: a first working build, with a mid-build check-in
- Weeks 5 to 6: evals and refinement to a final, measured build
Ships: one workflow live in production, its ROI measured. The one we prioritize together, scoped so we don’t overreach.
Who builds it
Your engineers do the engineering.
Your engineers build it, on your systems. They write the integration code and own the deploy path, the same code they’ll run afterward. My job is the part they don’t do every day: managing the stakeholders, defining the spec, and running the evaluations that prove the thing works. Clean split, your team on the engineering, me on the AI method and the proof.
That’s the point, and it’s the opposite of how most external AI work leaves you. The risk CIOs raise most about outside help is knowledge ending up outside the building, the consultant who leaves and takes the understanding with them. Here there’s nothing to transfer at the end, because your team built it as they went. They know exactly what was built, because they built it. They can operate it, extend it, and take the next workflow without me.
The engagement is designed to make me unnecessary, on purpose.
Blast radius
Where your data goes, and what touches your systems.
Plain answers to what your security team will ask. Personal data is redacted before any model call. You stay the controller; model providers are processors under a DPA, with no training on your data. Access is scoped to what the build needs and nothing more, in writing, in the discovery spec. Nothing is bought, connected, or deployed without your approval.
The technical dossier shows the full data-governance design on a real worked example, redaction, controller/processor split, retention, and an EU AI Act risk-tier read, with the code available for your engineer to audit.
Answering the board
Built to be measured, so you can answer the board.
What fails a board review isn’t 92% accuracy instead of 95%. It’s not being able to say how you know it works at all. So evaluation is built in from the start: measured accuracy against a labeled set your own people define, the gaps stated honestly, and the impact in hours and dollars. When a director asks “what did this return, and how do we know,” you have the number and the method, not a vendor’s slide.
Why me
Why me, specifically.
Twenty years across product, design, and engineering: ServiceNow’s workflow platform, consumer scale at Reddit, service-design rigor at GOV.UK. I’ve shipped real systems inside large organizations, which is why this is shaped around your production reality, not a demo. I run one or two of these at a time. Not a platform you license or a body shop you staff, one senior person who builds the first workflow with your team and leaves them able to do the next.
The proof isn’t a testimonial. It’s a working system you can inspect end to end, with its full build and evaluation published, gaps included. Judge the work, not the pitch.
Bring your hardest question.
Twenty minutes, engineer-to-engineer if you like: your stack, your constraints, your security posture, and whether this is the right shape of risk for you. No deck.
Or send it to your engineer first: the technical dossier →