Harvey, Opus 2 and Pandektes: acquisitions and funding

You must document the data sources, processing arrangements and human checkpoints for each integrated legal platform before deployment, and record these findings in writing so you can demonstrate compliance later if an outcome is challenged.

The prompt is an analysis of 9 October 2026 of integrated legal platforms combining knowledge, document management and AI agents, which argues that consolidation in legal technology creates longer, less transparent chains between input and output, shifting risk from visible to embedded. The analysis examines three recent expansions: funding and acquisitions that each touch a different part of the legal workflow. In our assessment, the development means you can no longer treat vendor investment as a proxy for system reliability; you must verify the underlying architecture yourself before committing sensitive work to an integrated platform.

What changes when legal platforms integrate knowledge, documents and AI?

When a vendor combines searchable legal knowledge, document bundling and AI agents in one environment, reliance grows on sources, model versions and processing arrangements that sit outside your direct control. The chain between case file and output lengthens, and visibility into each step diminishes. This matters because errors or data handling failures can now propagate through multiple layers before you notice them.

Which specific risks does this integration create?

• Stale or incomplete legal sources — searchable knowledge platforms may not cover all relevant legislation and rulings, or may lag in updates, leading to advice based on outdated law.
• Undisclosed data retention after acquisition — when a vendor acquires a document management tool, processing and storage arrangements may change without transparent disclosure to existing users.
• Uncontrolled agent behaviour — AI agents may drift from their defined task or produce outputs that cannot be traced to a specific decision point.
• Opacity in error propagation — when multiple systems feed into one workflow, it becomes harder to isolate where an error arose and how far it has spread.
• Vendor lock-in without exit rights — commitment to an integrated platform without contractual export rights or exit clauses leaves you dependent on the vendor's continued operation and goodwill.

What must you verify before adoption?

1. Record which legal sources the platform covers and at what update frequency — document in writing before deployment which areas of law, legislation and rulings are included and how often they are refreshed.
2. Obtain and review the processing agreement for document storage and retention — confirm where bundles are stored, how long they are kept, and whether those arrangements remain unchanged after any acquisition.
3. Define and document mandatory human approval points per workflow — specify which decisions require human review and record evidence of those approvals as you would for any privileged system access.
4. Establish an audit trail for each output — ensure you can trace which model version, which data sources and which human approvals contributed to each result.
5. Negotiate exit and export rights before commitment — secure contractual rights to export your data and workflows in a portable format if you need to leave the platform.

How should you treat vendor funding and acquisitions?

Investment and acquisitions are growth signals, not quality marks. A vendor's decision to acquire a security tool or raise capital tells you the sector recognises certain risks; it does not tell you that a specific deployment in your matter is safe or reliable. You must perform your own verification regardless of the vendor's track record or funding.

Where does this fit in your broader governance?

These verification steps belong in your recurring AI governance process, not as a one-off procurement check. Treat each expansion of capability—whether a new feature, a new data source or a new integrated partner—as a point at which you must re-verify the underlying architecture and document your findings. That way the choice for more capability remains deliberate rather than a dependency you discover only when something fails.

Tooling can help you track these verifications and flag when arrangements change, but the judgment about whether a specific platform is fit for a specific matter remains yours. No vendor checklist or audit framework can replace your own assessment of the risk you are willing to carry and the transparency you need to defend your decisions later.