Control of company AI data involves several decisions: ownership, export, access, storage, processing and retention. Evaluate each one separately. A label such as “private” or “self-hosted” needs a clear explanation of the actual system behind it.
Agree ownership and usable exports
Identify the assets involved: original documents, structured records, relationship mappings, workflow configurations, prompts and generated outputs. Ask the agreement to explain the rights and responsibilities for each, including any third-party material.
Then ask what you can actually retrieve. A useful export may need source references, record identifiers, relationships and attachments as well as the visible text. Include configurations and operating instructions where those are part of the agreed handover.
Test an export before depending on it. Can someone understand the fields, reconnect related records and use the information elsewhere? Exporting data and reproducing a working application are different tasks. Clarify what migration assistance, conversion work and fees would apply.
Know who can access and change information
List the roles involved: employees, administrators, implementation partners, support staff and connected services. Give each the access its work requires and establish who can approve changes.
Review how access is granted, monitored and removed. Include former employees, expired projects and support arrangements that have ended. An account inventory should show which application or integration uses each connection and who owns it.
Hosting also leaves operational responsibilities to allocate. The AWS shared-responsibility model, for example, distinguishes provider responsibilities from customer responsibilities, which vary by service. Ask for an equally clear division of work in the deployment you choose.
Separate storage from AI processing
Your company records may live in one system while a model runs somewhere else. If an application sends selected text to a cloud model for an answer, that text is processed by the remote service even when the original database remains under your control.
Map the complete journey: source system, application, retrieval or search service, model provider, connected tools and result storage. Include operational logs and monitoring services. Ask which information is sent at each step and whether a smaller amount would do the job.
A local application can use cloud inference. A cloud-hosted application can also offer specific access and deployment controls. Assess the actual components and arrangements instead of inferring the whole system from one hosting label.
Check retention, logs and backups
Ask separate questions about model training, prompt retention, request logging, caching, conversation storage and abuse monitoring. A restriction on training does not answer all the other questions.
Google Cloud’s data-retention documentation illustrates these distinctions by describing training restrictions alongside feature-specific logging, caching and retention conditions. Check the current documentation and settings for the exact service being proposed.
Extend the review to your own application. How long are records, prompts, results and diagnostic logs kept? Who can delete them? What happens to search indexes, cached copies and backups when a source record changes or is removed?
Agree a backup and recovery plan with an owner. Document backup retention, access and the process for restoring data. Test recovery on an appropriate sample, and make sure the team understands how a restore interacts with changes or deletions made since the backup.
An illustrative deployment decision
The company checks what those excerpts contain, who approves their use and what the selected service retains. It also sets access to the resulting summaries and decides how long application logs should exist.
The arrangement may meet the company’s needs, but “our database is under our control” describes only part of it. The processing path and operational settings still need to be understood.
Questions to settle before implementation
- Which data and configuration assets are covered by the agreement?
- What can we export, and has the export been tested?
- Who can read, change, administer or support each system?
- Where is information stored, and where is it processed?
- What do each provider’s current terms and settings permit?
- What happens to logs, caches, indexes and backups?
- Who maintains access, retention and recovery procedures?
- What changes if we switch a model, service or implementation partner?
Use the answers to choose a deployment that fits your requirements. Where regulated or sensitive information is involved, have the appropriate security, privacy and legal specialists review the proposed arrangement.
Protocorp’s approach is to make these choices explicit during scoping. Client ownership and deployment control are design objectives supported by agreed terms and a tested setup; the details depend on the services, infrastructure and responsibilities selected for the implementation.