Security & data handling
The boundary is a design decision.
Private AI and operational software need a clear account of where data lives, which model runs, what is recorded, and who can change the system.
Working principles
Controls belong in the architecture.
Specific controls are agreed for each client environment and workload. These principles describe our engineering posture; they are not a certification or a blanket compliance claim.
Keep the deployment legible
We map data flows, model calls, storage, and administrative access before deploying. For private AI, the target pattern keeps inference and data inside the agreed client boundary.
Pin what runs
Model and application versions need to be identifiable. A change to either should be evaluated against representative cases before release.
Record consequential behavior
Inference audit trails and application records should let authorized reviewers reconstruct what the system did and which version produced it. Retention is defined with the client.
Make access explicit
Access, routing, and review rights are designed around the people and systems that need them. The client environment and its existing controls set the implementation context.
Review agent use
AI agents can carry much of the build, while engineers remain responsible for review, integration, and acceptance of shipped work.
Bring the actual boundary.
If data residency, model access, audit needs, or a specific threat model determines the project, we should work from those requirements at the start. We can discuss the intended deployment and the controls it needs before committing to a delivery shape.
Discuss a system