An AI vendor risk assessment is how a business decides whether a new AI service is useful enough, controlled enough, and clear enough to bring into everyday work. It is not a pile of paperwork. It is a short, practical review before a tool receives company information, connects to an account, or starts shaping decisions that matter.
That pause is valuable because AI often enters through familiar software. A meeting platform adds an assistant. A customer system offers a summary feature. A browser extension promises faster research. Someone finds a tool that can draft emails or search documents in minutes. The feature may solve a real problem, but it can also create a new route into files, mailboxes, customer records, and business knowledge.
The goal is not to reject useful technology. It is to make a clear decision before convenience becomes an unmanaged dependency. This checklist gives owners and teams a way to ask the right questions, set proportionate safeguards, and leave a record the next person can understand.
Start with the business use, not the product demo
Begin with one plain sentence: what work is this AI vendor meant to improve? “Use AI for productivity” is too broad to review. “Summarize internal project meetings, with the meeting owner checking the summary before it is shared” is specific enough to assess. A clear use case reveals the information involved, the people affected, and what could go wrong if the output is incomplete or wrong.
Ask who will use the service, who benefits, and what happens if it is unavailable. Then ask whether the tool is only drafting or summarizing, or whether it will recommend, decide, send, approve, or change something. The closer a tool gets to customer commitments, payments, hiring, access control, security response, or legal obligations, the more deliberate the assessment should be.
This is consistent with the NIST AI Risk Management Framework, which frames AI risk as an organizational question, not merely a software question. A business does not need a research lab to apply that idea. It needs to know the purpose of the tool, the person accountable for it, and the boundary between useful assistance and an uncontrolled decision.
1. Map the information the vendor will receive
The first serious question is not “Does the vendor have AI?” It is “What can it see?” List the information that people might type, upload, summarize, retrieve, or expose through a connection. Include direct prompts and attachments, but do not stop there. An assistant connected to a calendar, shared drive, mailbox, customer system, or meeting platform may see far more than a person remembers entering.
A simple classification makes the decision easier. Public information, such as published website copy, generally presents the least concern. Internal information, such as procedures or draft plans, should stay in approved business accounts. Confidential and restricted information needs the closest attention: customer records, employee information, financial details, passwords, access tokens, security designs, incident evidence, private contracts, and regulated data should not enter an AI service by default.
Write down the exceptions, too. If a business has a real reason to use sensitive information, the review should state exactly what is allowed, which account must be used, who may do it, and what controls make that use acceptable. A vague promise to “be careful” does not give a busy team a reliable rule.
2. Review connections and permissions before turning them on
An AI vendor can create exposure even when employees never paste a sensitive prompt. Integrations are often the bigger issue. A meeting assistant may access recordings. A document tool may search shared folders. An email assistant may read messages and contacts. A browser extension may see pages a user opens. Treat every connection as a separate decision.
Ask for the minimum access needed for the approved use. If a tool can summarize a selected meeting, it may not need access to every calendar, recording, and file. If it can draft from material pasted into a controlled workspace, it may not need a connection to the company drive. Limiting permissions reduces the amount of harm a single mistake, compromised account, or vendor problem can create.
The NIST Generative AI Profile specifically calls out added privacy, data-protection, and information-security risks from third-party generative AI integrations. For an owner, that is a useful reminder to review both the product and the connections around it. Ask which systems the vendor can reach, what permissions it requests, whether access can be narrowed, and how an administrator can remove it later.
3. Ask the vendor how data is handled, retained, and used
Vendor terms can be dense, but the business does not need to become a contract specialist to ask clear operational questions. Start with these: Is business data used to train or improve the vendor’s models? Can that setting be disabled for the account type being considered? Where is information stored? How long is it retained? Can an administrator delete it? Does the service make data available to subprocessors or connected third parties?
Look for answers that fit the actual workflow, not just a reassuring marketing statement. An answer about public consumer use may not apply to a business plan. An answer about prompts may not cover uploaded documents, support tickets, meeting recordings, or connected cloud storage. If the vendor cannot explain a material part of its data handling in a way the business can understand, that uncertainty is itself a decision signal.
Keep the review proportionate. A low-risk tool used only for public writing may need a short record of approved use. A tool that handles customer files or connects to company systems deserves documented answers before anyone expands the pilot. The decision should be based on what the business plans to do, rather than the most generous claim a product page makes.
4. Confirm that the business can manage the account
When AI becomes part of work, a personal account is rarely enough. Use a company-managed account so the business can control who joins, who leaves, which settings apply, and what happens when responsibilities change. Review whether administrators can enforce stronger sign-in protection, restrict sharing, control integrations, review relevant activity, and remove users promptly.
This is not bureaucracy for its own sake. A managed account gives the business a way to keep ownership when an employee leaves or a vendor changes a feature. It also makes it easier to separate an approved pilot from an unapproved personal experiment. If the service cannot support the level of account control the use requires, reduce the scope or choose a different approach.
For the same reason, name a business owner for the vendor relationship. That person does not need to run every technical setting. They do need the authority to approve a use, revisit it, request help, and stop it when the risk changes. Good ownership makes the review usable after the excitement of a new tool fades.
5. Set a human review point before the tool influences a decision
AI can draft, summarize, sort, and suggest. It should not quietly become the final decision-maker for a commitment that affects a customer, employee, payment, security control, or legal obligation. The assessment should say who checks the output and what they must verify before the business acts.
For a customer email, that may mean verifying facts, account details, and promises before sending. For a finance workflow, it may mean keeping the ordinary approval controls in place. For a security use, it may mean prohibiting automatic account changes or requiring a qualified person to confirm any recommended action. The more material the consequence, the less appropriate it is to treat a confident-looking output as a completed decision.
Write the rule in language people can use: “The tool may prepare a first draft, but a named employee verifies factual claims and gives the normal approval before it is sent.” That is much more useful than a vague instruction to use good judgment. It also fits with an AI acceptable use policy that gives everyone the same daily boundaries.
6. Decide how the vendor fits the business’s wider technology risk
An AI tool is still a supplier. It should enter the same broader risk conversation as other software, service providers, and connected systems. The NIST Cybersecurity Framework supply-chain guide recommends identifying technology suppliers, considering how critical they are, defining requirements, and including relevant suppliers in incident planning and recovery.
For a smaller business, that can be a short checklist. How important is this vendor to daily work? What happens if it is unavailable? Who will contact the vendor during an incident? What data or access would need to be removed if the relationship ends? Is there a backup process if the feature fails or produces an unsafe result? The answers help the business avoid learning its dependencies only during a disruption.
Record the decision as approved, approved with safeguards, pilot only, or not approved. An approved-with-safeguards decision might require a managed account, limited integrations, public or internal data only, a named reviewer, and a review date. A pilot-only decision might limit the tool to a small team until the business has better evidence. Clear status prevents a temporary experiment from quietly becoming standard practice.
7. Keep a short decision record and revisit it
A completed assessment should leave a useful record. Capture the vendor, the approved use, the accountable owner, the data limits, allowed connections, account requirements, human review step, decision status, and next review date. Keep it with vendor and technology records where the business can find it when people or systems change.
Review the decision when the vendor adds a major feature, requests broader permissions, changes how it uses data, connects to a new business system, or moves from a limited test into an important workflow. Also give teams a simple way to report accidental sharing, unexpected behavior, or an unapproved connection. Early reporting gives the business time to limit exposure and improve the rule without turning a small mistake into a larger problem.
Businesses that want a broader starting point can use the AI risk assessment template alongside this vendor review. The two work together: one helps assess the proposed use, while the other focuses on the provider, data, access, and safeguards that make the use possible.
How H3Systems helps businesses review AI vendors
H3Systems helps businesses turn informal AI adoption into clear, workable decisions. That begins with understanding the proposed workflow, the information involved, the accounts and connections required, and the safeguards that fit the business. From there, owners and teams can set practical data limits, approval steps, access controls, and review points without making useful technology unnecessarily hard to use.
The aim is not to slow down progress. It is to give businesses a reliable way to say yes with conditions, run a limited pilot, or pause a vendor that asks for more access than the value justifies. If your team is evaluating an AI tool or discovering that one is already in use, request a Risk Review with H3Systems to turn the questions above into a decision that fits your systems and responsibilities.
