IBM Bob self-hosted: development AI enters the sovereign boundary
IBM has announced a self-hosted deployment option for IBM Bob, its agentic software-development platform. It enables development and modernisation capabilities to run in on-premises, private-cloud, sovereign-cloud, or air-gapped environments. The signal matters for organisations that cannot move sensitive code, data, or workflows outside their perimeter, but it does not on its own turn a coding assistant into a sovereign system.
1. Bringing AI to the code, rather than code to AI
IBM says Bob can run in customer-controlled environments, with supported self-hosted models or, in a hybrid configuration, connections to external model services. The announcement targets teams managing proprietary code, regulated data, or critical infrastructure that must govern data residency, security policies, and AI operations.
The option reduces an obvious exposure: moving application context and source code to a public tool. Yet a specific implementation still needs to document its selected model, management plane, telemetry services, updates, and support access. Those elements remain decisive in establishing the effective processing boundary.
2. Self-hosting is a topology, not complete evidence
In an AI-assisted development chain, the repository is only one part of the sensitive data. Prompts can include secrets or incidents; code indexes and embeddings can contain intellectual property; and logs can expose contextual excerpts and identities. Container images, dependencies, network calls, licence keys, and platform-administration tools also need to be examined.
An “on-premises” configuration must therefore be reviewed with the same rigour as an external service: where requests travel, who can read traces, which data leaves for service quality, and which updates can change behaviour. Where external models are connected, the architecture and contract need to distinguish what remains inside the controlled boundary from what leaves it.
3. Operational control must cover the delivery cycle
For an organisation in Belgium or France, the useful question is not only “where is the tool installed?” but “who can run what, with which data, and with which traceability?” A pilot should isolate a non-critical repository, apply separate identities for reading, generation, and deployment, and block by default writes to a production branch, Odoo, an ERP, or a CI/CD chain.
Generated recommendations should remain subject to code review, testing, and existing security controls. Teams need to export logs, reconstruct the context behind a suggestion, revoke a connector or token quickly, and redeploy a known version. This evidence is more useful than a location claim alone.
4. Moving from a sovereignty promise to a production decision
Before production, the organisation should request an inventory of components and flows, an operations-and-support responsibility matrix, and an exit scenario. It should also test the disconnection of an external model, secret rotation, index deletion, environment restoration, and the preservation of human controls over code changes.
Operational recommendation: treat the coding assistant as a high-privilege processing chain. Map repository, context, model, identities, logs, updates, support, and exit; do not allow connections to Odoo, an ERP, or CI/CD until least-access, revocation, and recovery tests have been documented.
Assess sovereign development AI