Choose an AI Model for Sensitive or Regulated Data

Choosing an AI model for sensitive or regulated data means matching the model and its hosting arrangement to the information, rules, and risks involved. Before sending real data, identify what it contains, where it may be processed, and what your organization requires; then verify those points with the provider and your privacy, security, or compliance team.

What You’ll Need

• An inventory of the data you plan to use, including personal, confidential, financial, health, or other restricted information.
• Your organization’s applicable policies, contracts, and regulatory obligations, plus a contact in privacy, security, legal, or compliance.
• Details of the intended task, users, integrations, and consequences if the model produces an incorrect or exposed result.
• Documentation from candidate providers about data handling, security controls, model training, retention, subprocessors, and deployment options.
• A safe test dataset with synthetic or appropriately de-identified records. Do not use real sensitive data for initial trials unless approved.

Step-by-Step

1. Describe the use case and impact. Write down what the model will do, who will use it, what information it needs, and whether its output affects people, money, eligibility, safety, or important decisions. Separate low-impact drafting or summarization from tasks that could materially affect someone. Define what the model must not do, such as make a final decision without qualified human review.
2. Classify the data before comparing models. Identify direct identifiers, sensitive attributes, confidential business information, and any data subject to contractual or sector-specific restrictions. Include prompts, uploaded files, conversation history, outputs, logs, and feedback: all may contain sensitive data. Ask your data owner which classification applies and whether the proposed processing is permitted. If the data can be minimized or replaced with synthetic examples, do that first.
3. Turn requirements into pass-or-fail questions. List required processing locations, retention limits, access controls, encryption, audit records, deletion procedures, incident notification terms, and restrictions on secondary use. Specify whether the provider may use prompts or outputs to train or improve models, and whether that setting is enforceable for your account. Requirements vary by organization and jurisdiction, so do not assume one certification or a provider’s general privacy statement settles every obligation.
4. Compare the full service, not just the model. The same model may be offered through different products or deployment arrangements with different controls. Review the provider, hosting environment, API or application, connected tools, and any subcontractors. Determine where data is sent and stored, who can access it, how long it remains, and whether backups or support records are included. Ask for current written documentation and contractual terms; marketing claims alone are not evidence that your exact configuration meets a requirement.
5. Check whether the model fits the task. Evaluate accuracy, stability, language coverage, context limits, and known failure modes using representative, non-sensitive test cases. Test for fabricated facts, leakage of information included in context, and responses to adversarial or ambiguous inputs. Compare candidate models on the same task and scoring criteria. A more capable model is not automatically safer, and a smaller or locally hosted model still needs evaluation and operational controls.
6. Assess deployment and access controls. Decide whether an approved cloud service, a dedicated environment, or local or self-hosted deployment is appropriate. Local hosting can reduce some external data transfers, but your team then owns patching, access management, monitoring, backups, and infrastructure security. In any setup, use organization-managed accounts, least-privilege access, strong authentication, and approved integrations. Prevent sensitive prompts from being copied into unmanaged consumer tools.
7. Run a controlled pilot. Start with synthetic or de-identified data and a limited group of trained users. Test the complete workflow, including uploads, retrieval, plug-ins, logs, and output storage. Measure errors and privacy risks, check that human review works, and confirm that users can report incidents. Keep the pilot within approved boundaries; de-identification does not guarantee that a record cannot be re-identified.
8. Get the required approval and document the decision. Give reviewers the use case, data classification, provider terms, technical configuration, test results, and mitigations. Record why the selected option meets the requirements, what remains unresolved, and who owns each control. Do not put regulated data into production until the relevant internal approvals and contractual checks are complete.
9. Monitor and revisit the choice. Set an owner and review schedule. Track model or service changes, access, incidents, output quality, retention settings, and changes to data or regulations. Reassess before adding a new data type, user group, integration, or consequential use. Keep a tested fallback, such as a manual process, for outages or a model that no longer meets requirements.

Common Mistakes

• Choosing by benchmark or reputation alone. General capability scores do not establish privacy, security, or suitability for your specific workflow.
• Assuming “not used for training” means no retention. Training, operational logging, abuse monitoring, backups, and support access are separate questions. Confirm each in the applicable terms and settings.
• Checking only the model vendor. An application, cloud host, connector, or analytics tool may receive the same information. Map the full data path.
• Testing with real records too early. Use approved test data until the pilot and processing arrangement have been reviewed.
• Treating local deployment as automatically compliant. It changes who operates key controls; it does not remove the need for governance, security, testing, or legal review.
• Skipping human oversight. Fluent output can still be wrong. Set review requirements according to the impact of the task, and make clear who is accountable for decisions.

Tips

• Send only the minimum information necessary. Remove names and identifiers where they are not needed, and check whether combinations of details could still identify someone.
• Keep prompts and outputs out of ordinary logs unless those logs have an approved purpose, access controls, and retention schedule.
• Ask providers specific questions about your intended product and configuration, and keep dated copies of answers and terms.
• Use role-based access and separate development, testing, and production environments. Restrict who can export conversations or connect external tools.
• Define a clear escalation path for suspected exposure, inaccurate high-impact output, or an unexpected change in provider behavior.
• Recheck the arrangement when providers change terms, subprocessors, model versions, or data-handling settings.

Troubleshooting

The provider cannot confirm where data is processed: Pause the evaluation for real data. Ask for written details about processing and storage locations, subprocessors, and support access. If the answer remains unclear, involve your privacy or procurement team and consider another option.

The service retains prompts longer than policy allows: Check whether retention can be disabled or reduced for the exact plan and interface you intend to use. Verify the change in writing and test the configuration. If it cannot meet the required limit, do not send that data.

Test outputs are unreliable or reveal information: Stop the pilot, preserve relevant evidence securely, and report the issue through your organization’s process. Review prompt design, retrieval permissions, and data exposure; do not treat prompt wording alone as a security boundary. Retest with non-sensitive data after controls are changed.

A team member has already entered restricted data: Follow your organization’s incident-response procedure promptly. Record what was shared, when, and through which service, without copying the sensitive content into additional channels. Ask the provider and internal security or privacy team about containment and deletion, and do not assume that deleting the conversation removes every stored copy.

Requirements conflict with usability or cost: Do not silently waive a control. Reduce the data or task, change the workflow, or compare a different deployment. Ask the accountable internal reviewer to assess any proposed exception before use.

Frequently Asked Questions

Is a locally hosted model always safer for regulated data?
No. It may reduce some transfers to an outside service, but security depends on configuration, access, updates, logging, and operations. Evaluate the whole environment.

Can I use a public AI tool if I remove names?
Not automatically. Other details may identify a person, and the tool may retain prompts. Follow your organization’s rules and confirm the tool’s data handling before use.

Does a security certification prove a model is compliant?
No. A certification may provide useful evidence about a defined scope, but it does not prove that your use case, configuration, contract, or data is covered.

Should I choose the most accurate model?
Accuracy matters, but so do privacy, security, reliability, access, and operational fit. Compare models on representative tasks and use human review where errors could have significant consequences.

How often should we reassess our choice?
Set a regular review schedule and reassess sooner after changes to the data, use case, provider terms, model, integrations, or applicable requirements, or after an incident.

Related

• Tetris Friends: Play With Friends Online
• AI Companions in Education: What Schools Should Know
• Story Driven Mystery Game: What to Look For