Getting from stage 2 to stages 3 and 4 doesn’t happen in a vacuum. It requires organizational buy-in. In most cases, this isn’t a top-down initiative. It’s developers who’ve experienced the productivity gains of stages 1 and 2 pushing their organizations to remove the barriers that prevent them from going further. They’ve seen what’s possible, and they want access to the tools and policies that unlock it. This is only natural – and it is the way most technological adoption happens in software development. The early adopters experiment, demonstrate value, and then advocate for broader access. The business’s role is to listen, understand the potential, and figure out how to enable it safely and effectively.
The conversation with the business usually starts with a simple question: ”Can we use AI with our actual code?” And the answer is never just ”yes” or ”no” – it’s ”let’s figure out how.”
The AI Landscape
The first thing to understand is that ”using AI” isn’t a single thing. There’s a broad spectrum of options, each with different characteristics around data handling, operational overhead, capability, and control. Understanding this spectrum matters because it means there’s no valid reason to say ”we can’t use AI” — only a choice about which model fits your constraints.
PaaS / product-level tools are the most accessible entry point. GitHub Copilot, Claude Code, JetBrains Junie, OpenAI Codex – these bundle AI directly into developer tools. You subscribe, you use them, and the provider handles everything. For many teams, this is where AI adoption starts and where it delivers the fastest return.
SaaS API access gives you more control over the integration. You call provider APIs (OpenAI, Anthropic, Google, and others) directly and build the AI into your own workflows and tools. The provider hosts the model; you decide how to use it.
Managed cloud hosting adds another layer. Services like Azure AI, AWS Bedrock, and GCP Vertex AI let you choose which model to run while the cloud provider manages the infrastructure. This can offer more flexibility around data residency and configuration while keeping operational overhead manageable.
Self-hosted and local models give you complete control. You run the model on your own infrastructure – whether that’s a company server or a developer’s workstation. Nothing leaves your network. The trade-off is that you take on the operational responsibility of running and maintaining the model.
Each of these options has its place. The right choice depends on your organization’s requirements, and there’s no single answer that fits everyone.
Terms of Service and Data Ownership
One of the most important and least understood aspects of AI adoption is what actually happens to your data when you send it to an AI provider. This is where reading the Terms of Service matters – and the major providers have become increasingly explicit in their terms on this front.
The key provisions to look for are training data usage, data retention, and data ownership. Most major AI providers – OpenAI, Anthropic, Google – now explicitly state in their API and enterprise terms that they do not use your inputs or outputs to train their models. This is a meaningful legal commitment. When a company writes ”we do not train on your data” into their Terms of Service, they are legally binding themselves to that promise. Violating it would expose them to breach of contract claims and regulatory action.
Data retention is the next question. How long does the provider keep your prompts and responses? Enterprise agreements typically offer zero-retention or short-retention windows (often 30 days or less for abuse monitoring, then deleted). Some providers offer complete zero-retention options where your data is processed in memory and never written to disk on their side. Understanding the retention policy tells you what your actual exposure window is.
And then there’s ownership. Your data is yours. The major providers’ terms are clear on this: you retain all rights to your inputs, and you own the outputs generated from your prompts. The AI provider has no claim on the code it helped you write or the analysis it produced from your data.
This matters because it removes one of the biggest blockers to adoption. When your legal team can read a Terms of Service that explicitly says ”we don’t train on your data, we delete it within X days, and you own everything,” the conversation shifts from ”can we use this?” to ”how should we use this?”
That said, Terms of Service are not all created equal. Consumer-tier products (the free chat interfaces) often have very different terms than API or enterprise agreements. The free version of a tool might absolutely use your conversations for training. The enterprise API version of the same tool might guarantee the opposite. This distinction is critical: make sure your developers are using the right tier with the right terms for the sensitivity of the work they’re doing.
This is the current landscape, Terms of Service are also evolving when providers adapt to the needs of the customers and the regulatory environment. You could start by reading your provider candidates current terms and see what they say about data usage, retention, and ownership. If the terms are not clear or don’t meet your requirements, ask the provider for clarification or look for alternatives that do.
Data Sharing and Restrictions
Every organization needs to decide what data can be shared with AI services and what cannot. This is an internal policy decision that depends on the nature of the business, the sensitivity of the data, and the organization’s risk tolerance.
Some companies are comfortable sharing production code and internal documentation with cloud-hosted AI tools, especially when enterprise Terms of Service guarantee that the data won’t be used for training. Others take a more restrictive approach, limiting AI usage to non-sensitive code or requiring that all AI interactions stay within controlled environments. Both positions are valid, and many organizations land somewhere in between.
The important thing is that this decision is made deliberately rather than left to individual developers to figure out on their own. A clear policy – whatever its boundaries – gives developers confidence to use the tools that are available to them without second-guessing every interaction.
Compliance and Deployment Options
For organizations operating under regulatory frameworks like GDPR, the question isn’t whether you can use AI – it’s how, when, and where. Under GDPR, sending data to an AI provider requires the same data processing agreements you’d need for any cloud service. The same principles that govern your existing data flows apply…
Asmo Korkiatupa
Software Architect
Hands-on Software Architect with strong AI and cloud expertise
