AI Employee Platform RFP Checklist: 50 Questions and Proof Requests

§ 01What Is an AI Employee Platform RFP?

An AI employee platform request for proposal is a structured request for product, security, privacy, reliability, commercial, and contractual evidence from vendors being considered for a standing AI role.

It is narrower than a complete enterprise risk program and broader than a feature checklist.

Use the RFP to decide what is documented, demonstrable, independently assured, contractually committed, still unverified, or unavailable. The bounded AI employee pilot should then test the remaining performance uncertainty against a baseline, representative cases, staged authority, and precommitted exit rules.

When a 50-question RFP is justified

Use the full checklist when the AI employee will:

• read confidential or personal data;
• access authenticated applications;
• send external messages;
• create, update, approve, delete, or publish records;
• run on schedules or events without a person present;
• retain memory across tasks;
• delegate to other agents;
• affect customers, money, rights, security, or regulated work;
• become operationally important; or
• require an enterprise agreement, security review, or data processing addendum.

A read-only research role using public information may not need the same process as a role that updates a CRM, emails customers, or runs commands on a workstation.

What this RFP should not become

Do not ask 50 generic questions before defining the job. Vendors will answer against their broadest product capability while your team evaluates a narrower deployment.

Do not use the RFP to:

• select a role;
• replace security or legal review;
• reproduce an industry framework without scoping;
• award points for irrelevant enterprise features;
• demand sensitive vendor internals that can be verified another way;
• force every answer into Yes;
• turn roadmap promises into current capability; or
• declare a pilot successful before it runs.

The RFP converts a defined role into proof requests.

§ 02What Should You Send Vendors Before the 50 Questions?

Every vendor should receive the same 1-2 page scope sheet. Without it, “supported” can mean different things in every response.

Role scope sheet

The scope sheet should use real workflow objects: account, record, file, recipient, tool operation, task state, source, approver, and accepted outcome.

Action-risk tier

The tier is an internal scoping device, not an industry standard. Increase rigor when the action’s blast radius grows.

Buyer constraints

Tell vendors which answers are knockout requirements before they respond.

Examples:

• no inference-data training;
• named processing regions;
• central access revocation;
• enforceable approval before defined actions;
• exportable action evidence;
• incident notification within a contractual period;
• deletion within an accepted period;
• supported identity controls;
• a minimum service commitment; or
• an acceptable exit format.

A vendor can give an excellent answer and still be wrong for the deployment.

§ 03How Should Vendors Format Their RFP Responses?

Reject free-form sales essays. Require one structured row per question.

Use evidence codes

No artifact proves everything. A SOC report may support control assurance but not your role’s denial behavior. A demo may prove behavior but not create a contractual service level.

Protect sensitive evidence

Allow vendors to:

• redact customer identifiers;
• provide audit reports under NDA;
• use a secure data room;
• give an auditor’s report instead of exploit details;
• demonstrate a control without disclosing secrets; and
• describe an architecture boundary without publishing attack-enabling configuration.

The objective is sufficient assurance, not forced disclosure.

§ 04Who Should Review the RFP?

No single reviewer owns all 50 answers.

CISA’s Secure by Demand Guide recommends considering product security before procurement, putting appropriate requirements into the contract during procurement, and continuing assessment after purchase. That lifecycle matters for AI employees because model, prompt, tool, memory, and provider changes can alter behavior after the contract is signed.

§ 05The 50 AI Employee Platform RFP Questions at a Glance

The 10 domains mirror the operating path from role definition through termination. Five Yes answers in one domain cannot compensate for a failed knockout requirement in another.

§ 06Domain 1: Role and Operating Architecture - Questions 1-5

These questions establish whether the product carries standing work or only exposes a capable model, prompt, or workflow surface.

What a strong response shows

A strong response connects:

role → trigger → task state → context → plan → action → evidence → postcondition → handover

It also separates native product capability from professional services, custom code, third-party tools, and buyer-operated components.

Question 5 does not require source code. It requires enough architecture to understand the value chain, data path, control ownership, and failure dependencies.

Knockout candidates

Consider a knockout when:

• the role cannot be paused or retired;
• duplicate triggers can repeat consequential actions;
• unfinished work cannot be distinguished from completed work; or
• critical provider dependencies are undisclosed.

§ 07Domain 2: Tools, Integrations, and Execution - Questions 6-10

An AI employee creates operational risk when reasoning becomes action. Ask about exact operations, not connector logos.

What a strong response shows

The vendor should distinguish:

• connection from authorization;
• tool availability from supported operation;
• model choice from execution policy;
• retry from safe recovery;
• browser reach from durable integration; and
• artifact generation from confirmed delivery.

The question is not whether the platform can reach thousands of tools. It is whether the selected role can use five required operations within a bounded, observable action path.

Agent-specific security evidence

OWASP’s AI Agent Security Cheat Sheet identifies tool abuse, privilege escalation, data exfiltration, memory poisoning, excessive autonomy, cascading failures, and unbounded cost as agent-specific risks. Its recommendations include least-privilege tool scopes, high-impact approval, structured monitoring, cost and retry limits, and adversarial testing.

Ask the vendor to map its evidence to the threats that apply to your role.

§ 08Domain 3: Identity, Permissions, and Approvals - Questions 11-15

The full AI employee permissions and approvals framework explains how to build an action envelope. These five RFP questions ask whether a platform can enforce it.

What a strong response shows

The response should identify:

• which controls the platform enforces;
• which controls come from the connected application;
• which controls require middleware;
• which controls are only instructions;
• which plan includes the control; and
• how a denied, expired, revoked, or altered action appears in evidence.

Do not mark a vendor down merely because a buyer-desired control sits in the connected system. Mark it down when the combined path cannot enforce or prove the boundary.

Knockout candidates

For a consequential role, common knockout failures include:

• no central stop;
• no enforceable approval;
• approval parameters can change after review;
• no operation-level restriction;
• no administrator attribution; or
• no workable identity model for the deployment.

§ 09Domain 4: Context, Knowledge, and Memory - Questions 16-20

Persistent memory improves continuity and expands the attack and privacy surface. The AI employee memory guide provides the lifecycle design; the RFP should require proof of the platform controls.

What a strong response shows

Strong memory answers are object-specific. They distinguish among:

• chat history;
• uploaded documents;
• retrieved knowledge;
• task state;
• generated summaries;
• learned preferences; and
• action evidence.

The vendor should explain which layer is authoritative, which is advisory, and what happens when two layers conflict.

Ask for propagation evidence

Delete or correct a source record, then test:

1. direct retrieval;
2. generated summary;
3. open task;
4. long-term memory;
5. audit record; and
6. export.

Deletion of a visible document does not prove removal from derived context, backups, or required audit evidence.

§ 10Domain 5: Data Privacy and Lifecycle - Questions 21-25

Data can flow through the platform, model providers, connector brokers, email services, cloud infrastructure, support tools, analytics, logs, memory, and external actions.

What a strong response shows

The vendor distinguishes:

• controller and processor roles where applicable;
• customer content from service telemetry;
• active storage from backup retention;
• account deletion from object deletion;
• inference processing from training use;
• primary vendor from subprocessor; and
• legal retention from product convenience.

Do not accept “zero retention” without identifying the provider, data type, endpoint, plan, and exception.

Match the RFP to applicable law and policy

Privacy requirements depend on data, people, location, sector, and use. Ask qualified privacy and legal reviewers to tailor this domain.

The RFP should record the organization’s requirement. It should not ask the vendor to decide which law applies to the buyer.

§ 11Domain 6: Security Assurance and Supply Chain - Questions 26-30

AI employee platforms combine normal SaaS risk with models, prompts, retrieval, memory, tools, code, browsers, and third-party services.

What a strong response shows

A certificate is useful when the scope matches the purchased service. It is not a universal pass.

Ask:

• Which legal entity was assessed?
• Which service and infrastructure were included?
• Which period was covered?
• Were important controls customer-operated?
• Were exceptions found?
• Is the report current?
• Does the evidence cover AI-specific components?

Use broader frameworks when the risk requires them

The 50 questions are intentionally shorter than a complete control catalog. CSA’s July 2026 AICM v1.1 overview says its AI-CAIQ contains 320 questions aligned to 247 controls. Enterprise security teams can use that resource for deeper self- and third-party assessment rather than expanding an improvised spreadsheet indefinitely.

§ 12Domain 7: Evaluation, Reliability, and Safety - Questions 31-35

The vendor must show how it knows the system works - not only that the model can produce a good answer.

What a strong response shows

The evaluation set should resemble deployment:

• same role;
• same tool classes;
• same data types;
• same action risk;
• realistic failures;
• explicit acceptance;
• severity-aware errors;
• known limitations; and
• versioned results.

NIST’s AI RMF Core calls for documented test sets, evaluation under conditions similar to deployment, production monitoring, and response and recovery processes. Ask the vendor which artifacts support each lifecycle stage.

Do not confuse benchmark and role proof

A benchmark can support the capability it measures. It does not automatically prove:

• connector correctness;
• permission enforcement;
• memory isolation;
• reliable triggers;
• task handover;
• incident containment; or
• cost per accepted outcome.

Record the benchmark’s task set, date, configuration, judge, and scope - then keep the role evaluation separate.

§ 13Domain 8: Observability and Human Governance - Questions 36-40

The buyer should be able to reconstruct work without asking the same model to narrate what it remembers.

What a strong response shows

Strong evidence separates:

• user instruction;
• system or role instruction;
• retrieved content;
• model decision;
• policy decision;
• human approval;
• execution request;
• external-system result; and
• final task state.

The buyer needs structured evidence that shows inputs, control decisions, actions, results, and responsibility without depending on a model-generated explanation of its own behavior.

Test the investigation path

Give the evaluator one suspicious external message and ask them to find:

1. which event started the task;
2. which role handled it;
3. which source influenced the decision;
4. which instruction and model version applied;
5. which approval was requested;
6. which tool call executed;
7. what the external system returned;
8. what the platform retried;
9. what the human changed; and
10. how the task ended.

If the evidence exists but cannot be found during an incident, observability is incomplete.

§ 14Domain 9: Pricing, Implementation, and Support - Questions 41-45

The AI employee cost framework separates vendor price from setup, integration, review, correction, monitoring, and failure exposure. The RFP should make every vendor quote the same work.

When “build internally” remains on the shortlist, require the internal sponsor to answer the same ownership questions through a three-year build-versus-buy AI employee analysis. Framework access and prototype labor are not substitutes for a costed evaluation, security, memory, monitoring, incident, change, and exit plan.

What a strong response shows

The quote should normalize:

• task mix;
• context volume;
• tool calls;
• model tier;
• artifact type;
• retries;
• failures;
• concurrency;
• review;
• correction;
• support;
• implementation; and
• term.

The lowest subscription may create the highest operating cost. The RFP must preserve both.

Keep commercials current

Require a quote-valid-until date, renewal rules, overage treatment, usage-export format, price-change notice, termination right, and assumptions.

Do not freeze a pricing page into a multi-year decision without a contract.

§ 15Domain 10: Contract, Continuity, and Exit - Questions 46-50

The last five questions determine whether the evidence survives a dispute, outage, provider change, acquisition, or termination.

What a strong response shows

The contract should not say “autonomous work” in the product description and leave every consequence undefined in the terms.

Review the following materials for contradictions:

• product documentation;
• security response;
• privacy policy;
• DPA;
• terms;
• SLA;
• support policy;
• order form;
• statement of work; and
• insurance or assurance evidence.

NIST’s third-party guidance

The NIST Generative AI Profile recommends use-case-based supplier assessment, third-party inventory, ongoing monitoring, incident planning, fallbacks, and contract terms addressing ownership, rights, security, serious-incident notification, response times, and critical support.

That is the procurement lesson: a current answer must become an owned control, continuing monitor, or enforceable term where the risk requires it.

§ 16Which Evidence Pack Should Every Vendor Return?

The questionnaire is incomplete without a deliverable list.

Core evidence pack

Request:

1. product and architecture overview;
2. role, task-state, trigger, and handover documentation;
3. operation-level integration matrix;
4. permission and approval configuration evidence;
5. identity and administrator-control matrix;
6. data inventory and flow diagram;
7. current subprocessor list;
8. object-level retention and deletion schedule;
9. sample data and evidence export;
10. redacted structured run and action logs;
11. evaluation methodology and sample result;
12. change and regression policy;
13. incident-response summary and notification term;
14. security assurance package;
15. same-workload commercial quote;
16. implementation plan and RACI;
17. support policy and proposed SLA;
18. standard terms and DPA;
19. business continuity and exit summary; and
20. current gaps, betas, custom dependencies, and roadmap items.

The request should specify an acceptable secure delivery method.

Evidence freshness rules

An undated screenshot is not durable evidence.

Evidence ownership

For every accepted artifact, record:

• buyer owner;
• source vendor;
• secure location;
• reviewed date;
• approved use;
• expiration or refresh trigger;
• linked RFP question;
• linked risk or requirement; and
• final disposition.

Procurement evidence becomes operational evidence only when someone maintains it.

§ 17Which Six Tasks Should the Vendor Demonstrate Live?

The RFP asks what the product can do. The proof session checks a small number of claims before a full pilot.

Demo 1: Normal role path

The role should:

1. wake from the approved trigger;
2. load the correct context;
3. complete the requested work;
4. use the permitted tool;
5. satisfy the postcondition;
6. attach evidence; and
7. enter the correct final state.

Demo 2: Denied action

Ask the role to perform an operation outside its action envelope.

Require:

• technical denial;
• clear reason;
• no external side effect;
• correct task state;
• escalation if appropriate; and
• structured log evidence.

Demo 3: Duplicate or stale trigger

Send the same event twice, then replay it after the task has expired.

Require:

• one valid task;
• no duplicate external action;
• visible deduplication or rejection;
• bounded retry; and
• correlation to the original event.

Demo 4: Conflicting or poisoned context

Place a malicious or stale instruction inside a retrieved document and provide a newer authoritative policy.

Require:

• source hierarchy;
• conflict detection;
• no unauthorized persistence;
• safe refusal or escalation; and
• evidence of which source controlled the decision.

Demo 5: Tool failure after partial progress

Make the destination unavailable after one step succeeds.

Require:

• correct partial-state record;
• no repeated side effect;
• bounded retry;
• recovery or compensation path;
• human escalation; and
• final reconciliation.

Demo 6: Investigation and export

Give a reviewer the task identifier and ask them to reconstruct:

• trigger;
• role;
• context;
• instruction;
• model;
• decision;
• approval;
• action;
• result;
• retry;
• cost; and
• final state.

Then export the relevant record.

These six tasks validate shortlist claims. They do not replace a representative pilot with a baseline, sample design, duration, KPI thresholds, and go/no-go criteria.

§ 18How Should You Evaluate the 50 RFP Answers?

Use the evidence scale and weights already defined in the AI employee platform selection guide. Keep this RFP focused on producing the evidence that guide needs.

Classify every answer

Keep gates outside the average

Potential gates include:

• high-risk approval;
• central revocation;
• safe failure and interruption;
• action evidence;
• acceptable training/data-use terms;
• required identity control;
• acceptable incident term;
• retention and deletion fit; and
• workable exit.

One failed gate can stop the procurement even if the vendor has 49 strong answers.

Price every “Partial”

Partial can mean:

• higher subscription tier;
• professional services;
• custom integration;
• buyer-built middleware;
• connected-system control;
• manual review;
• additional vendor;
• policy process;
• delayed roadmap; or
• accepted risk.

Translate it into owner, cost, delivery date, operational burden, and residual risk.

§ 19Which RFP Answers Should Become Contract Terms?

Contractualization should follow impact.

Do not attempt to put every marketing sentence into a contract. Bind the facts whose failure would change the purchase or create unacceptable exposure.

Resolve contradictions

If a sales answer, security questionnaire, privacy policy, terms, and order form disagree:

1. identify the conflict;
2. ask the vendor to resolve it in writing;
3. identify which document controls;
4. update the RFP disposition; and
5. do not rely on the most favorable non-binding statement.

The procurement record should show what the buyer actually accepted.

§ 20What Are the Most Common AI Vendor RFP Red Flags?

A vague answer is not always evidence of a bad product. It is evidence of incomplete diligence.

§ 21Which 15 Questions Should a Small Team Ask First?

For a low-risk role, begin with these question IDs:

1. Q1: How is the persistent role represented?
2. Q3: Which triggers start work, and how are duplicates handled?
3. Q6: Which exact tool operations are supported?
4. Q9: What happens on timeout or partial tool failure?
5. Q11: How granular are permissions?
6. Q13: Does approval bind to the exact action?
7. Q14: How is access or the role revoked?
8. Q16: Which context and memory types are stored?
9. Q18: How is context isolated?
10. Q21: Where does data flow?
11. Q22: Is any data used for training or improvement?
12. Q24: What are retention and deletion periods?
13. Q30: How are AI-specific incidents handled?
14. Q36: Can the action path be reconstructed and exported?
15. Q41: Which work consumes billable units?

Add all 50 questions before the role gains external action, sensitive data, broad access, operational criticality, or enterprise commitment.

The small-team version should reduce administrative weight, not remove the controls that contain the role.

§ 22How Does CellCog Map to This RFP?

CellCog should receive the same 50 questions as every shortlisted vendor.

Its current public pages answer part of the RFP and identify the gaps a buyer should take to sales, security, privacy, and legal review. The observations below reflect public materials reviewed in July 2026.

Evidence available publicly

Public evidence helps a buyer prepare. It does not answer every operation-, tenant-, plan-, assurance-, SLA-, incident-, export-, or contract-specific question.

Questions to send CellCog directly

Ask CellCog to identify and demonstrate:

• operation- and resource-level permission granularity;
• approval binding, expiry, replay protection, and revocation behavior;
• structured action-log fields and export;
• memory provenance, correction, isolation, and deletion propagation;
• identity and administrator controls available by plan;
• current independent security assurance and scope;
• incident notification and support commitments;
• service levels for the intended deployment;
• fixed-workload credit consumption;
• complete role, memory, task, evaluation, and evidence export; and
• deletion and transition behavior at termination.

These are evidence requests, not claims that the capability is absent. Public materials do not establish the complete answer.

What CellCog should be asked to prove live

CellCog AI Employees publicly describes scheduled and event-triggered shifts, persistent memory, task boards, approvals, tools, KPI dashboards, and handovers. Use one scoped role to demonstrate:

1. wake;
2. context retrieval;
3. tool action;
4. denied action;
5. exact approval;
6. connector failure;
7. handover;
8. action evidence;
9. usage record; and
10. export.

Then send the same script to every shortlisted general-purpose platform.

Move qualified vendors from comparison to evidence review

First, compare candidate shapes and current vendor claims on the AI employee platform comparison. Then send the 50-question response template to each shortlisted vendor. If CellCog remains qualified, use its contact path to request the plan-specific evidence and commercial terms that public pages cannot establish.

§ 23Copyable AI Employee Platform RFP Response Template

Procurement header

• Buyer:
• Role:
• Business outcome:
• Action-risk tier:
• Systems:
• Data classes:
• Regions:
• Volume:
• Required identity controls:
• Required service level:
• Retention requirement:
• Contract term:
• Knockout requirements:
• Response due:

Vendor header

• Vendor:
• Product:
• Proposed plan:
• Proposed region:
• Primary respondent:
• Security respondent:
• Privacy/legal respondent:
• Commercial respondent:
• Response date:
• Evidence data-room location:

Question response row

Evidence register

Gap register

§ 24The Short Version

An AI employee platform RFP works when every answer has:

1. a scoped role;
2. a clear status;
3. a named product tier;
4. an enforcement or operating explanation;
5. customer responsibility;
6. current evidence;
7. a known limitation;
8. a roadmap field separate from present capability;
9. contractual status; and
10. an accountable owner.

The 50 questions cover the entire chain:

role → trigger → context → tool → permission → action → evidence → outcome → incident → exit

Send the same chain to every vendor. Accept a claim only at the level its evidence supports. Put material promises into the appropriate agreement. Then let the pilot answer the remaining question: can this platform perform the role reliably enough to buy?