Free tools Windows power users keep installed
One-click scans. No signup required.
Do not treat “safe” or “private” as a yes-or-no property of an AI vendor. Decide whether the specific product, configuration, data handling, and safeguards are suitable for your use case—and whether the vendor can support its claims with evidence and enforceable terms. Start by defining the potential harm, then trace your data, test the evidence, inspect the contract, compare vendors on the same criteria, and set review triggers.
1. Define the use case and what could go wrong
A vendor’s general safety statement cannot establish that its service is appropriate for a particular workflow. The risks depend on the task, who uses the system, who may be affected, and what happens if the model is wrong, manipulated, unavailable, or exposes information.
- Describe the task, intended users, people affected, and decisions or actions the AI may influence.
- Record whether a person reviews outputs before they are used, and what that review involves.
- Classify the data involved, the scale of use, foreseeable misuse, and the consequences of an error or disclosure.
- Identify applicable sector and jurisdictional obligations; consult qualified counsel where needed.
NIST’s voluntary AI Risk Management Framework is intended to help manage AI risks across design, development, use, and evaluation. Its AI RMF 1.0 page says the framework is being revised, so record which version a vendor uses when mapping its controls. NIST describes trustworthy AI through characteristics including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed. Those characteristics must be considered in the context of use, not treated as a universal pass/fail badge: NIST’s AI trustworthiness characteristics.
2. Trace your data through the service
Ask for a data-flow diagram or a written account detailed enough to follow each category of information from collection to deletion. Get answers for the exact product plan, configuration, and geography you are considering; a broad marketing statement may not describe every tier or setting.
#1 Best Overall
- What enters: prompts, uploaded files, generated outputs, feedback, telemetry, and account or support information.
- Who or what can access it: the vendor’s staff, support teams, human reviewers, subprocessors, model providers, and other third parties.
- Where it goes and why: storage and processing regions, service delivery, abuse monitoring, evaluation, fine-tuning, or general model training.
- How long it remains: retention periods for each data type, including logs, backups, and evaluation records.
- How it is removed: deletion mechanisms, timing, exceptions, backup handling, and what happens at contract termination or service decommissioning.
Check whether the vendor’s answers match the definitions, exceptions, and commitments in the data processing agreement (DPA), privacy policy, product terms, and order form. In a 2024 staff post, the FTC Office of Technology said companies should honor privacy commitments made in promotional materials, website terms, or marketplaces—including promises not to use customer data for model training—and noted that omitting material information about collection or use may matter. The post is agency staff commentary, not a vendor scorecard or a legal opinion for every jurisdiction: FTC Office of Technology, “AI Companies: Uphold Your Privacy and Confidentiality Commitments”.
NIST’s Generative AI Profile also identifies retention, data security, third-party access, and possible leakage after decommissioning as governance concerns. See the profile, released July 26, 2024: NIST AI 600-1.
3. Ask for evidence that matches each claim
A policy statement is not the same as evidence that a safeguard works under your conditions. Ask the vendor to connect each important claim to a document, test, responsible party, date, and applicable product or model configuration. Distinguish independently verified evidence from vendor-provided material, contractual commitments, and unanswered questions.
Safety and performance
For tests or evaluations, ask what was tested, who conducted it, which scenarios and methods were used, and which model version and configuration were assessed. Request a results summary, the operating conditions, known limitations, relevant incidents and remediation, and the vendor’s change history. Evidence from a different model, deployment, or task may not answer whether the service is suitable for yours.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Security
Ask for the scope and dates of independent audits or certifications, along with information relevant to your deployment: access controls, encryption, isolation, vulnerability handling, incident response, and security testing. A certification or audit badge may support a claim about specified controls, but it does not prove that an AI system’s outputs are safe. NIST identifies AI-related security concerns such as adversarial examples, data poisoning, and attempts to extract models, training data, or intellectual property through endpoints: NIST’s AI trustworthiness characteristics.
Privacy
Ask for an assessment relevant to your workflow and data. It should address purpose limitation, minimization, access, retention, deletion, applicable data-subject handling, and privacy risks that can arise from inference or generated outputs. For AI/ML used in digital identity systems, NIST SP 800-63-4 specifies provider information-sharing requirements that include training methods, dataset descriptions, update frequency, and test results, as well as privacy risk assessments for personal information processed in those systems. Treat those as identity-system guidance, not a universal rule for every AI procurement: NIST SP 800-63-4.
4. Inspect upstream dependencies and contract terms
Many AI services depend on upstream models, APIs, tools, data providers, or other suppliers. Ask the vendor to identify the dependencies relevant to your service, including embedded AI and fine-tunes, and which third parties can access your content. Find out what changes—such as a new model provider, subprocessor, or data use—will be reported to you and when you can reassess.
Make the commitments you rely on explicit in the contract, DPA, or service-level agreement (SLA), rather than assuming that a sales answer or general web statement will govern your deployment. Depending on the use case, address:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
- Permitted data uses, ownership, and usage rights.
- Security requirements and access to relevant evaluation or audit information.
- Retention, deletion, and handling at termination.
- Incident notification, cooperation, and support responsibilities.
- Service availability, response expectations, liability allocation, and transition or fallback arrangements.
NIST’s Generative AI Profile recommends use-case-based supplier assessments and contract clauses that allow organizations to evaluate third-party generative AI processes and standards. The profile is guidance; the specific terms you need depend on your use and applicable obligations.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.5. Compare vendors on the same evidence standard
Ask every vendor the same questions and record evidence, not just assurances. Weight the criteria according to the potential harm in your use case. NIST cautions that trustworthiness characteristics can involve trade-offs that need context and transparent justification; an unknown should remain unknown, not be scored as favorable by default.
| Comparison area | What to compare | What an unresolved answer means |
|---|---|---|
| Data use and retention | Training and secondary-use terms, retention periods, deletion, backups, and handling after termination. | You do not yet know whether the vendor’s data practices fit your requirements. |
| Data access and location | Who can access content, regional handling, subprocessors, and deletion mechanisms. | Data exposure or location may not be adequately understood for this deployment. |
| Safety evidence | Relevance of tests to your task, model and configuration, methods, results, and limitations. | A generic claim or test on a different setup does not establish performance for your use. |
| Security and incidents | Control scope, audit dates, vulnerability handling, and incident response. | You lack enough information to judge the controls or response arrangements you rely on. |
| Model and change transparency | Model/version identification, update cadence, and notice of material changes. | You may not know whether the evidence still applies after a change. |
| Human oversight and redress | Where human review occurs and how affected people can challenge or correct outcomes, if relevant. | Responsibility for reviewing or addressing problematic outputs remains unclear. |
| Contract rights and remedies | Whether key data, security, evaluation, notification, and service commitments are binding and what recourse applies. | An assurance may not give you a clear contractual right or remedy. |
| Operational fallback | How service disruption, suspension, or a vendor change would affect the workflow and what alternatives exist. | Continuity may depend on a single supplier without a defined response. |
6. Keep the assessment current after approval
Approval applies to an assessed service, configuration, data flow, and use case—not necessarily to every later version or deployment. Keep an inventory of AI vendors and the data each can affect. Record the assessed model or service version and configuration, and assign an owner to review the service periodically.
Set reassessment triggers for material product, model, data-use, subprocessor, or contract changes; incidents; new use cases; and changes in data sensitivity or impact. Before deployment, define who can escalate concerns, when use may be suspended, how the work can fall back to another process, and how incident communications will be handled. NIST’s Generative AI Profile recommends ongoing monitoring and contingency processes for high-risk third-party systems.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
