A fast-growing AI product can reach employees before procurement, legal or security teams have evaluated it. Instinct illustrates that tension. TechCrunch reported that the viral AI startup raised $350 million at a $2.5 billion valuation, while also identifying privacy concerns around the product. Those concerns should not be presented as proof of misconduct. They are, however, a useful warning for operators: popularity, capital raised and investor confidence do not establish that a tool is suitable for handling customer records, confidential documents or proprietary work.
The practical question is therefore not whether a viral product is impressive. It is whether the business understands the product’s data flows, contractual protections and failure modes well enough to authorize a specific use. The following due-diligence process is designed for that decision.
Separate market validation from data-risk approval
Funding announcements answer questions about investor demand, growth expectations and access to capital. They do not answer the questions a business must resolve before adoption: What does the product collect? Who can access submitted information? How long is it retained? Can it be used to improve models? What happens after an account is closed?
Treat the TechCrunch report about Instinct as a prompt for investigation rather than a verdict. Reported privacy concerns deserve examination, but they are not equivalent to confirmed unlawful conduct. A responsible review should rely on the vendor’s current privacy notice, terms, product documentation, security materials and negotiated contract—not assumptions based on either publicity or criticism.
Begin by defining the proposed use narrowly. “Marketing wants an AI tool” is not reviewable. “Two copywriters want to generate first drafts from public product descriptions for four weeks” is. The second formulation identifies users, inputs, outputs, duration and business purpose. It also prevents approval for a low-risk task from becoming implicit permission to upload customer lists or unreleased strategy documents.
Map what enters the product—and what may remain there
Create a simple data-flow record before anyone starts a pilot. List every category the team expects to submit, including prompts, uploaded files, images, audio, contact details, browser data, device identifiers, generated outputs and user feedback. Account for information gathered automatically as well as content entered deliberately.
Then obtain clear answers to five retention questions:
- Where are prompts, files and outputs processed and stored?
- How long does the vendor retain each category?
- Are backups, logs and abuse-monitoring records governed by different periods?
- Can administrators or users delete data, and does deletion cover derived data and backups?
- What remains after account closure or contract termination?
Do not accept “we value privacy” as a substitute for operational detail. If documentation is ambiguous, request written clarification and preserve it with the review. Check whether product settings differ by plan: a free consumer account may provide fewer controls than an enterprise agreement.
Training deserves a separate decision. Determine whether business inputs, outputs, ratings or interaction logs may be used to train or improve models. Establish whether training is on by default, whether opting out applies retrospectively, and whether contractual language overrides public documentation. If the answer cannot be established, the safe assumption is that confidential or personal data should not enter the product.
Test consent, confidentiality and intellectual-property boundaries
Privacy review is not limited to personally identifiable information. Customer-facing teams may paste support conversations into a tool; recruiters may enter candidate details; marketers may upload photographs, testimonials or audience lists. The business must identify the lawful and promised basis for that processing, including whether existing notices and customer consent cover disclosure to this vendor and this purpose.
Confidentiality requires its own input rules. Prohibit trade secrets, credentials, security configurations, legal advice, unreleased financial information, contract material and data received under nondisclosure obligations unless the tool has been specifically approved for them. Labels help, but technical controls are stronger: block uploads where possible, restrict integrations and use data-loss-prevention rules for sensitive patterns.
Review intellectual-property terms in both directions. Who owns submitted material and generated output? What licence does the vendor receive? Does it promise not to train on business content? Are there restrictions on commercial use? Does the vendor offer any protection if generated material triggers a third-party claim? Even favourable terms do not guarantee originality, so externally published output still needs human review for copied expression, trademarks, false claims and inappropriate use of a person’s likeness.
Put authorization ahead of shadow AI
Blanket silence encourages shadow AI: employees adopt convenient tools through personal accounts because no approved path exists. Publish a short, accessible policy that classifies uses rather than merely naming products. For example, public-information drafting may receive lightweight approval, while customer data, regulated records, source code and confidential strategy require enhanced review or remain prohibited.
Assign decision rights. Security should examine architecture, access and incident controls; privacy or legal teams should evaluate processing terms, notices and jurisdictional obligations; the data owner should approve the business purpose; procurement should preserve negotiated commitments. One accountable executive should accept any residual risk. Individual managers should not be able to authorize sensitive use simply because a product is popular.
Where adoption is allowed, require company-managed accounts, single sign-on where available, multifactor authentication, role-based access and prompt removal of departing users. Administrators should be able to see which teams are active without creating unnecessary surveillance of employees. Maintain a vendor register recording approved use cases, prohibited data, contract owner, renewal date and next review.
Design a pilot that reveals risk instead of hiding it
A useful pilot constrains exposure while testing the assumptions behind approval. Select a small group, a defined workflow and a fixed end date. Use public, synthetic or deliberately de-identified material. Do not use live customer information merely to make the trial realistic.
Set success and stop criteria before launch. Success may include acceptable output quality, measurable time saved and reliable administrative controls. Stop conditions should include unexpected retention, unclear training status, unauthorized sharing, inability to delete records, material changes to terms, security incidents or repeated policy breaches.
Test controls directly. Delete a prompt and verify what the vendor says happens next. Remove a user and confirm access ends. Export available records. Examine whether links expose conversations, integrations copy data elsewhere, or outputs reveal information from another session. Document limitations rather than interpreting an absence of visible problems as proof of safety.
At the end, decide among approval for the defined use, approval with additional restrictions, remediation followed by another test, or rejection. Approval should expire or be reviewed when the vendor changes ownership, subprocessors, training practices, product architecture or contractual terms.
Prepare for incidents and vendor failure before signing
The final review should assume something goes wrong. Identify who employees contact after an accidental upload, suspected account compromise or inappropriate disclosure. The response plan should cover access suspension, evidence preservation, vendor notification, deletion requests, legal assessment and communication with affected customers or authorities where required.
Ask how quickly the vendor must report incidents, what information it will provide and whether those duties are contractual. Determine whether the business can retrieve its data in a usable format and continue operating if the service becomes unavailable, changes direction or fails. Avoid workflows that make a viral product the sole repository for essential records.
Before authorizing adoption, operators should be able to answer: what data is permitted; where it goes; how long it remains; whether it supports training; who can access and delete it; which legal, confidentiality and IP constraints apply; who approved the use; and how the business exits or responds to an incident. If any answer depends on guesswork, restrict the pilot or pause adoption. Momentum may justify a prompt review, but it never justifies skipping one.
