Ironclad

Ironclad is contract-lifecycle software for teams that want a configured first pass on routine third-party paper without turning contract judgment into an unattended task. Its May 15, 2026 help documentation describes AI Assist for first-line review of vendor agreements and NDAs, editor redline suggestions, summarization, group permissions, and Playbooks. [S1]

The best fit is a legal-operations or in-house legal team with repeatable agreement types, approved clause positions, named exception owners, and enough control over its intake and approval process to test one workflow in parallel. Ironclad's July 2025 redlining documentation says Playbooks can flag non-standard terms and offers a Clause Approver role for terms configured to require approval. [S2]

The trade-off is configuration and evidence. A Playbook can make routine review more consistent, but incomplete matter facts, vague positions, incorrect source documents, loose permissions, or a reviewer who accepts a plausible edit without checking it can create real commercial risk. Public materials do not establish the buyer's exact module availability, implementation plan, model and subprocessor terms, data path, support, retention, or exit rights.

Best for: legal teams with a high volume of repeatable inbound agreements, settled playbooks, accountable legal owners, and a pilot boundary that can be evaluated against current work.

Not for: a buyer seeking automated legal judgment or signing; a team without approved positions and exception routing; or an organisation unable to verify permissions, data governance, and record export for the tenant it plans to use.

Run a first-pass review of third-party paper

• Trigger: A vendor agreement, NDA, or comparable third-party document arrives within an approved contract type and risk boundary.
• Inputs: The received document, correct legal entity and commercial facts, approved Playbook positions and fallbacks, required clauses, applicable jurisdiction, and exception-routing rules.
• Output: Flagged clauses and proposed changes or questions. Ironclad describes AI Assist for Playbook-based first-line review of vendor agreements and NDAs on third-party paper. [S1]
• Human checkpoint: The assigned legal owner checks material terms, facts, clause coverage, exceptional risk, and the final negotiating position.
• Success measure: Material-issue coverage, missed-issue rate, false positives, legal-owner overrides, exception age, and turnaround time.

Propose and control contract redlines

• Trigger: A review stage identifies a clause that needs a change or a lawyer asks for a redline.
• Inputs: Current contract version, configured Playbook rules, pre-approved language, matter context, required clause roles, and tracked-change settings.
• Output: Suggested redlines with explanations and a new version after an authorised user applies a change. [S1][S2]
• Human checkpoint: A Clause Approver or responsible lawyer evaluates whether the suggestion fits the buyer's position and commercial facts, then accepts, modifies, rejects, or escalates it.
• Success measure: Accepted-suggestion rate after legal review, material rework, rejected-redline reasons, version-control defects, and time to approved draft.

Intake third-party paper before legal review

• Trigger: An external counterparty contract begins the buyer's third-party-paper workflow.
• Inputs: The source agreement, counterparty and request details, correct entity and deal context, intake fields, routing policy, and assigned owner.
• Output: Pre-filled intake information and a routed workflow. Ironclad's April 23, 2026 release note says the Intake Agent reads a counterparty contract, extracts key data, follows linked URLs, and pre-fills a launch form. [S3]
• Human checkpoint: The requestor and legal intake owner verify that extraction, document scope, linked material, commercial facts, and routing are correct before review proceeds.
• Success measure: Extraction accuracy, missing or wrong-field rate, routing corrections, intake-to-review time, and percentage requiring manual rebuild.

Pilot Word-based review with Jurist

• Trigger: The legal team chooses one approved agreement class and Playbook for a controlled Word workflow.
• Inputs: A Microsoft Word agreement, selected Playbook, approved language, actual deal facts, permitted reference material, and test cases.
• Output: A Word-based AI-assisted review and redline workflow. Ironclad's June 11, 2026 release log says Jurist runs natively in Microsoft Word; its April 23 entry describes redlining whole contracts using team-generated Playbooks. [S3]
• Human checkpoint: The legal owner checks a sample of routine and hard cases, approves exceptions, and decides whether results can move beyond the pilot boundary.
• Success measure: Agreement with independent legal review, source and fact accuracy, redline acceptance, missed material issues, rework, and user adoption.

1. The buyer chooses one agreement class and documents its playbook: required, permitted, and restricted positions; fallbacks; escalation rules; legal entity; fact source; and accountable owner.
2. A requestor or intake workflow supplies the contract and business context. Ironclad's release log describes an Intake Agent for extracting data and pre-filling third-party-paper intake; this must be tested on the buyer's actual documents and linked material. [S3]
3. AI Assist or Jurist reads the selected content and Playbook and produces flags, suggestions, or redlines. Ironclad says AI Assist can work in the editor and via Playbooks, and that users can review, modify, or accept suggested changes. [S1]
4. The assigned legal owner evaluates the factual and legal fit, rejects weak output, resolves exceptions, and decides the negotiating position. Ironclad says a configured Clause Approver role controls approval of non-standard language; that role is a workflow control, not proof that a buyer's governance is sufficient. [S2]
5. The buyer preserves the contract version, Playbook version, source facts, output, decision, exception, and correction record needed to reproduce the review and recover if a configuration or output proves wrong.

The essential control is the chain from correct matter facts and approved legal position through suggestion, reviewer decision, final version, and external action. A fluent redline is not evidence that it reflects the buyer's policy or the contract's legal effect.

Verified facts from current primary sources

• Ironclad's May 15, 2026 AI Assist documentation describes editor suggestions, summarization, group permissions, Playbook-based first-line review, and user actions to review, modify, or accept suggested changes. [S1]
• Its July 28, 2025 Precise Redlining documentation says AI Playbooks flag non-standard terms or necessary document changes against configured rules and describes clause-approval permissions, suggested redlines, explanations, and version history. [S2]
• Its 2026 release log records Jurist in Word, Jurist redlining with team-generated Playbooks, and a third-party-paper Intake Agent with a release chronology. [S3]
• Ironclad's security page states encryption, US Google Cloud hosting, assurance claims, testing, and security documentation available through its portal. [S4]
• Ironclad's current public pricing page describes solution and deployment choices but does not show a public starting price on the page reviewed. [S5]

Vendor claims and B2Bagents assessment

Ironclad presents AI review as a way to make first-line contract work faster and more consistent. Its materials support the existence of the mechanisms described above, but they do not prove performance on another buyer's clauses, documents, counterparties, or risk policy. [S1][S2][S3]

Our assessment: Ironclad is most compelling where a buyer has enough recurring inbound work to justify a well-maintained Playbook and can measure whether it produces fewer manual passes without hiding material risk. It is less suitable where each contract is unusual, source facts are unreliable, positions are unsettled, or the legal team cannot invest in configuration and ongoing controls.

Material unknowns

• Public materials reviewed do not establish the buyer's price, licensing or usage unit, modules, implementation scope, success plan, service levels, renewal, cancellation, export, or transition rights.
• They do not establish the buyer's actual integrations, data sources, read/write authority, model and subprocessor path, prompt handling, data residency, retention, deletion, support access, backups, legal holds, audit logs, or incident terms.
• They do not establish legal accuracy, jurisdiction or language coverage, treatment of privilege, citation and source accuracy, performance on complex documents, exception quality, or how errors are corrected in the buyer's tenant.

Good-fit conditions: stable and frequent agreement types; written positions and fallbacks; a named owner for Playbooks; accessible contract and matter data; defined routing and escalation; and a controlled way to compare results with current legal review.

Poor-fit conditions: high-stakes or novel matters with no settled position; incomplete deal facts; a contract repository full of unvalidated data; unknown access or data terms; or an expectation that a tool will make legal or commercial decisions without accountable owners.

Likely failure modes: the wrong Playbook or jurisdiction is selected; a missing schedule or fact leads to a confident but unsuitable redline; a clause is misclassified or a required provision is missed; a user applies a change outside the intended authority; an intake extraction sends the matter to the wrong route; or an organisation loses the version, source, and decision trail needed to explain an outcome.

Controls: freeze the first pilot Playbook; require correct entity and matter facts; route non-standard terms to a named owner; retain versions and decision records; test permissions and revocation; sample both accepted and rejected suggestions; run difficult counterexamples; maintain a manual fallback; and test correction, rollback, export, and emergency disablement before broad rollout.

Begin with one document type, such as an inbound NDA or routine vendor agreement, where the legal team already has approved positions. Legal owns the Playbook and exceptions; legal operations owns workflow configuration and records; business owners supply correct commercial facts; IT and security verify access and data controls; procurement owns contracted scope and exit rights.

Ironclad's release log names Word, APIs, selected integrations, and workflow capabilities, but that does not establish their availability or authority for a particular buyer. Demonstrate each enabled interface from authentic input through extraction, Playbook selection, output, approval, export, access revocation, failure, correction, and recovery. [S1][S3][S5]

Ironclad's security page states TLS 1.2+ in transit, AES-256 at rest, US-hosted Google Cloud production servers, annual penetration testing, quarterly vulnerability testing, SOC 1 and SOC 2 Type II reports, ISO 27001/17/18, and a security portal. It also references a DPA with standard contractual clauses and disaster-recovery practices. These are public vendor statements; obtain the current reports, coverage, region, DPA, subprocessor and model terms, support access, retention, deletion, audit, incident, recovery, and contractual commitments that apply to the chosen edition. [S4]

Ironclad does not publish a starting price on the pricing page reviewed. The page says buyers can select contract-lifecycle, AI assistant, and eSignature solutions; deployment assistance or partners; integrations; additional instances; and a success plan. [S5]

Request an itemised proposal covering each product and AI feature, licensing or consumption unit, users, documents or workflows, implementation, integrations, training, support, usage limits, extra instances, contract term, renewal, cancellation, document and data export, transition assistance, and changes to Playbooks or integration scope. A demo or a narrow pilot should not be assumed to include production controls or full deployment services.

1. Scope: One routine inbound NDA or vendor agreement class with a frozen Playbook, named legal owner, documented facts, and a manual fallback.
2. Baseline: Measure current intake time, review time, turnaround, legal-owner changes, material issues found, rework, exception count and age, version errors, and total cost.
3. Test set: Include straightforward agreements and difficult conditions: non-standard liability, indemnity, IP, privacy, security, data-use, governing-law, missing-schedule, ambiguous facts, conflicting precedent, wrong-document, access-revocation, and counterparty-redline cases.
4. Pass threshold: Agree in advance on independently checked material-issue coverage, false-positive and missed-issue limits, correct routing, legal-owner override rate, approval completeness, record traceability, correction time, access behaviour, and total deployed cost.
5. Stop conditions: A material missed or unsupported position; unauthorised access, edit, send, or sign; untraceable source or decision; wrong jurisdiction or Playbook; inability to correct or export records; or a result that does not improve the baseline after legal review.

• Spellbook: Compare Word-centred review, Playbook administration, source handling, output quality, and legal-team workflow controls.
• Luminance: Compare document review and contract-lifecycle approaches by permissions, data handling, negotiation workflow, and record ownership.
• Legora: Compare configurable legal workflows, document and precedent use, Word workflow, exception routing, and governed legal-owner control.
• Harvey: Compare a broad legal-AI environment with an embedded contract-lifecycle platform on source coverage, contract process, integration, and buyer operating model.

1. What can AI Assist, Jurist, Intake Agent, and each enabled integration read, write, send, sign, share, store, retain, and export in our tenant? Show this with the actual service accounts and roles. [S1][S3]
2. How does a legal owner version and approve a Playbook, see the exact source and rationale for a redline, reject a suggestion, correct an error, and retrieve the full decision history? [S1][S2]
3. Which terms truly require a Clause Approver in our workflows, and can a user or workflow bypass, alter, or misroute that control? Demonstrate denied access and emergency disablement. [S2]
4. Which current security evidence and contractual commitments apply to our edition and region, including models, subprocessors, data and support locations, retention, deletion, legal holds, audit, incident, recovery, and export? [S4]
5. How does first-pass review perform on our contracts, non-standard clauses, jurisdictions, languages, and difficult factual patterns? Test against independently reviewed examples, not a clean demo document.
6. What does the commercial package include for AI modules, implementation, integrations, support, upgrades, term, cancellation, records export, and transition? [S5]