Contract risk scoring assigns a risk grade to agreements (or clauses), based on some predetermined view of what constitutes contract risk. Risk definitions could be determined by a vendor, or they could be custom for an individual organization deploying the technology.
Certain clauses - or wordings of clauses - have the potential to be high risk. These include:
- Restrictive covenants - exclusivity, non-competition, and (less so) non-solicitation.
- Most favored customer treatment.
- (Unlimited) limitation of liability.
Some other clauses could be medium-to-low risk, depending on the organization. These include (an incomplete list):
- Governing law, outside certain jurisdictions.
- Termination for convenience.
- (Lack of) insurance requirements.
- Specifics of how assignment or change of control work.
- (Lack of) compliance-ey terms, like anti-bribery or compliance with laws.
- (Lack of) confidentiality, and user or data privacy clauses.
- Destruction of confidential information without a request notification. (A personal pet peeve of mine - makes inadvertent breach likely.)
- Many more!
Of course, risk depends a lot on which way the benefits of an agreement run. For example, many organizations would find an exclusivity clause very high risk, but not if they were the beneficiary.
Some phrasings of clauses might be totally inoffensive, while other phrasings of the same clause could be highly problematic. For example, a limitation of liability clause really depends on what the actual limitation of liability is. Unlimited liability (depending on if it is mutual) will be unacceptable for some parties (generally, sellers/vendors, who are more likely to be liable if things go wrong), and highly constrained liability will be problematic for others (buyers, who would like to be able to recover if things go wrong (though, of course, there may be practical limitations to unlimited recovery from smaller sellers - eventually, their insurance will cap out and they will otherwise run out of money to pay out a really big claim)).
Contract risk scoring is highly dependent on what the end customer sees as risky. This means that—while an Embeddable Contracts AI system (like Zuva’s DocAI) can provide some of the underlying tech to build a contractual risk scoring system on—contract risk scoring software should probably be built by someone building an end-user facing application (like a CLM or contract analysis software system).
To implement a contract risk scoring system, you will probably assign scores to problematic clauses, and then set thresholds. In a very oversimplified example, you might say that an exclusivity or non-compete clause are each worth five points, no insurance requirement is worth three points, lack of any of anti-bribery, export control restrictions, compliance with law, data breach notification, data privacy clauses are each worth one point, and contracts with scores of four or higher are “red,” one–four are “orange,” and zero are “green.” Or whatever matters to you. It doesn’t necessarily need to be hard to build a contract risk scoring system. One Zuvan built one like the above over the course of a few days using a Contracts AI API feeding a risk scoring model.
As this example illustrates, contract risk is highly subjective. A vendor may provide some preset contract risk scoring metrics, but it wouldn’t be surprising if a customer needed to customize.
A contract risk scoring system can be useful because:
- It can help triage agreements for review. A company who implemented a contract risk scoring system could decide that low risk contracts can be signed without law department review, medium risk contracts can be reviewed and signed off on by an outsourced legal managed service provider, and high risk contracts need to be reviewed by specific people in the law department itself.
- It can help a legal department get a better understanding of its own contracts, and where it could best focus on remediation.
- This could be especially useful for a company that is regulatorily-challenged, more strict today on contract risk than it was in the past, or acquired in a bunch of companies and is uncertain what its acquired companies agreed to before joining up.
- It can help companies do due diligence on a potential acquisition, giving an additional window into risks of the deal. When you buy a company, you come to own its contracts. It also can help due diligence contract reviewers prioritize their contract review.
Some difficulties with building contract risk scoring AI include:
- To do contract risk scoring well, you need to be able to not only identify clauses, but also drill down into what they mean.
- E.g. (and as described above), whether a contract has a limitation of liability clause is probably less important for risk scoring than what exactly the dollar figure of the limitation of liability is.
- Clauses are often not mutual, and whether a clause is risky or not can depend on who it runs against.
- For example, if your counterparty pledges not to compete with you, that would likely be “high risk” for the counterparty but not for you.
It can currently be difficult for a Contracts AI to identify which party is which in a given clause without outside information (e.g., knowing if a party is sell-side requires knowledge of the deal outside the contract, however, it may be possible to know who is who based on defined terms used).
- Contracts can be risky because of things beyond their legal language. For example:
- It can be risky to do business with some people or organizations, and the economic and deliverable terms of contracts can expose one side or the other to great risk.
- A Business Associate Agreement can be very risky for a business if it isn’t HIPAA compliant.
A Contracts AI is unlikely to notice these issues.
If evaluating contractual risk scoring offerings, you should:
- Test accuracy on a range of documents (which ideally approximate what you think the system will see working for you).
- Consider whether it is possible to modify the system to meet your definition of risk.
- If modifying, figure out how much work this will be.