AI tools have changed the way we work, think, and create. Engineers proactively picked up Cursor, Claude Code, Copilot, ChatGPT, or you name it, getting quick victories and saving hours. By the time most companies started thinking about an AI adoption strategy, their teams were already three months in.
So, adopting AI is quite easy. What's harder is everything that comes after: who's connecting what to your data, are there any consistencies across teams, and how you measure whether any of it is working.
This is the part Johann Beukes deals with every day. He's the Chief AI Officer at Svitla Systems, a software engineering company with over 20 years of experience and clients such as Logitech, Thermo Fisher, and Ancestry. He works across banking, nuclear, and life sciences - industries where a gap in AI control is a risk to answer for.
At a recent CTO Craft webinar, Johann talked through what AI risk and control look like when you're building something real.
What is different now in how we manage risk and retain control in AI projects?
Today, we are not adding a tool or a system. We are adding intelligence. That changes the whole relationship you have with what you built.
When I wrote code earlier in my career, I knew exactly what it did. I wrote it, and I could test it. With AI, the closest I can get to explaining it is: we grow it.
It’s similar to planting trees. You know the species. You know what it needs. But you don't know how it's going to look when it's big. You're growing it, not building it.
That's a very different risk profile. With traditional software, something breaks, and you get a 500 error, a crash, or something visible. With AI, the error is a hallucination. It’s just a wrong prediction. Something subtly off that your users find before you do.
So, from day one of any project, we put measurements in place. We start with a model. We track model drift, estimate the model's expected performance, and determine when it starts moving outside that range. As AI models get new types of data, we need to ensure we monitor and measure them.
The second area is going to be the data, because you also have data drift. Think about 2020 as a data point. That's a massive outlier in any data set. When you're starting to train models, you have to account for those kinds of outliers and how the data will influence the model. You have to make sure that you understand when there are cycles or seasonality in the data. Before you even release it, you have to test and make sure that it is taken care of. The third area would be just kind of protecting against technology shifts. And that might be a little bit more strategic than anything else.
The data shapes the model. You have to watch both.
How do you scale an AI Proof of Concept into production?
We always build with scale in mind. Even in the PoC phase.
I've seen this a few times when a client comes to us with something that works and is genuinely impressive, built over the weekend. Then we try to move it into Azure and find out it's going to cost $20,000 a month in tokens, or the processing just can't scale. The prototype worked fine, but production is a completely different question.
The core team on any AI PoC needs three roles.
First, an architect who understands the technical feasibility of prototype or PoC scaling. Second, a machine learning engineer with the right specialization. Third, someone who owns the data layer.
That third role is different from what most teams expect. Traditional ETL is about accuracy, as you're reporting quarterly financials, every number has to be right. In machine learning, you're doing something else. You're filling gaps, imputing values, making data usable for an algorithm to learn from. You need pipelines that are repeatable, so that when you change one variable, you can see exactly what it did to the result.
What we don't do in the PoC phase is build everything around the AI before we know whether it works. No web app, no SAP integration, no APIs. That comes later. First, prove that AI can solve the problem at an ROI that makes sense. Then build everything else.
What does work with sensitive data in AI projects look like?
We worked with one of the banks in Florida. One of our engineers messaged and panicked because the company had handed the development team a full copy of the production database - client data, all of it. We had to fix that fast.
On the other end, we've worked on projects in nuclear energy. That meant moving to AWS GovCloud, the US government cloud, which offers the same services as regular AWS but with significantly more security requirements. That was probably the most secure project environment I've ever worked in.
Here's the challenge that sits in the middle: at some point in any AI project, you need to test with production data. Sample data gets you to a point, but not all the way. So, you have to build the mechanics that let you run models against real data without giving developers or contractors direct access to what they're computing on.
The way we handle this is through isolated environments: development, staging, QA, and a pre-flight environment. Pre-flight is an internal beta. Production data, controlled conditions, and no end users yet.
As mentioned above, with AI, there's no 500 error when something goes wrong. The error is a hallucination, a wrong estimation, something quiet. You want to catch that in the pre-flight.
We also migrate only the model between environments, not the notebooks, not the code that generated it. That code still gets reviewed, but you limit the risk by limiting what moves forward.
And the honest part: guardrails help, but they are never the 100% guarantee. The biggest AI companies in the world still ship hallucinations. If you understand that and plan for it, you're in a better position than if you assume it won't happen to you.
What core values do you teach your team when using Claude Code?
You have to prioritize workflow over tools. That's the main thing.
The tools are changing extremely fast. If you train people on a specific tool and the tool changes, you retrain them from scratch. If you train people on a workflow, the workflow survives the tool change.
Here's what ours looks like.
When a developer starts their day, they run a command, a skill that pulls context from three systems: the project management tool (usually Jira), the product requirements (Confluence, Google Docs, whatever the client uses), and the codebase itself. All that context comes in locally.
Then they work. Agents, direct coding, whatever the task calls for. When they stop, they run an end-of-session command. It pushes updates to Slack and Jira and saves everything that happened. We call it context loading and context dumping.
The skills are internal. We package them as a plugin with a built-in marketplace. When a client installs it, a wizard walks through the setup and customizes it for the project: Java, Python, C#, JavaScript. That customized version goes back into a company repo, so it's reusable across projects.
How do you monitor and audit MCP traffic?
We've started a couple of projects to test right now. We don't have one definitive answer.
We have network monitoring tools in place for typical security practices that monitor traffic. The tooling is still catching up to the problem. So, we start at the traffic layer: standard security monitoring, traffic patterns, the kind of thing any security-minded engineer would recognize.
On top of that, we use Datadog and similar tools for system-level behavior and logging. And we have custom agents that monitor AI-specific behavior.
The practical advice I give every client: don't give your AI tools access to all your systems at once. Give them access to one MCP. Let that MCP be the proxy: the single connection point to Jira, Outlook, databases, whatever. Now you have a single entry point to monitor, and you can understand how the system behaves before you expand its reach.
We treat MCP the same as we treat APIs: keys, tokens, and access controls. That part isn't new. The intelligence layer on top is what's new, and that's where better monitoring tools are still needed.
How do you adopt AI tooling without losing control of your codebase?
Start by figuring out which parts of your code matter most.
Not everything carries the same risk. A public-facing website is not the same as a proprietary algorithm sitting on a protected server. If you treat them the same, you're either wasting money or under-protecting something important.
We had a client at a nuclear facility with a codebase that connects to the internet, not directly public-facing, but connected. That code went through a completely different hardening and release process than the rest of their system. Different review cycles, different controls, different everything.
If they ran their entire organization that way, they'd never ship anything. Probably 80-90% of their code doesn't need that level of process. The answer is to know which part does.
It's like having a Rolex and a Casio. The Rolex goes in the safe. The Casio goes on your wrist when you're out running errands. Both are watches. They don't get the same treatment.
The AI adoption version of this: identify what's critical, isolate it, and govern it differently. You're not going to eliminate all risk because cybersecurity is a good parallel here, attackers always find ways through. Your job is to understand the risk, reduce it where you can, and be clear-eyed about what you're accepting when you ship.
The final word
You can't control what you don't measure. Model drift, data drift, MCP traffic, code governance - all of it comes back to the same thing. Know what normal looks like. Build the systems that tell you when something is moving away from it. And be honest about what your guardrails can and can't do.
