Traditional software testing is predictable. When something goes wrong, a developer can usually trace the problem to a line of code and fix it. "Working as designed" is clear and repeatable.
AI tools built on LLMs are only partly like that. Some parts are ordinary code, like the integrations that move data between systems and hard-coded rules. Those can be tested the usual way. The model is different. It learned its behavior from data, so a bad result doesn't always trace back to code, and fixing one case may not fix the next. It can also handle the same input differently from one run to the next, so someone must define what an "acceptable" output looks like. And because inputs vary so much, passing one case doesn't guarantee a similar one will pass. Testing can only show how often the model stayed within bounds.
The challenge is that many organizations still test AI like traditional software. When AI enters the picture, QA teams should make three practical changes around:
Traditional testing relies on output-matching. The tester decides the exact result ahead of time, and the test passes if the system produces it. That still works for some model results, like an invoice total. It doesn't work when the output is supposed to vary and there’s no single “match,” like a written note explaining why an invoice was flagged.
Behavioral bounds testing checks rules instead of exact answers. The team identifies what AI must and must not do, then checks each result against that list. If the result follows every rule, it passes, no matter how it's worded.
Take an agent that processes vendor invoices. An output-matching test would compare its note to a pre-written one and could fail due to different wording. A bounds test checks whether the agent: pulled the correct total and vendor, flagged any invoice that doesn't match a purchase order, sent anything over the approval limit to a manager, or left a field blank instead of making up a value it couldn't find.
Those bounds must be written down before testing starts, and teams often skip this step. Without them, testers judge results by feel. Two people can reach different verdicts on the same output, and there's no record of what "acceptable" meant at go-live.
Each test case should also run more than once. A single pass says little about a system that can change from run to run. If a check holds on 49 of 50 runs, the team needs to know that. Whether the one failure matters depends on what the agent is allowed to do.
Traditional software usually fails the same way every time. For example, if an approval workflow is configured to send invoices to the wrong manager, every invoice goes to that same wrong manager. Someone notices quickly, and the fix is obvious.
AI failures are harder to predict. An agent can pass a full test cycle and then fail in production on inputs nobody thought to try, like a vendor name in another language or a scanned invoice with a table the model misreads. It’s impossible to list every failure ahead of time, so testing effort should match how much damage a failure could do.
That means sorting assets into risk tiers before testing starts. A tool that summarizes internal meeting notes doesn't need the same coverage as an agent that drafts journal entries or emails customers. Tiering should consider the following:
Higher tiers get more test cases, more repeated runs, deliberately tricky inputs, and monitoring after launch. Someone also needs to own the tier assignments. Otherwise, each asset often gets tested at whatever level the project timeline allows.
For public companies, any AI asset that's part of a SOX-relevant process, such as reconciliations, accrual estimates, or approval routing, should have its controls validated before go-live. Auditors will want evidence that the control is designed properly and works consistently. "We tried it a few times and it looked fine" is not enough.
The bigger gap comes after launch. Model providers release new versions, sometimes on their own schedule. A model swap or prompt edit can change behavior as much as a code release can. Any update to a SOX-relevant AI asset should trigger regression testing against the documented bounds, and the results should be kept as audit evidence.
Many change management procedures don't account for this. They were written for code deployments and configuration changes, and an AI model update might not register as a change at all. Fixing the procedure now is easier than explaining the gap to an auditor later.
These three changes require QA teams to make decisions earlier than they might be accustomed to. Don’t rush to implement AI tools without the upfront work around behavioral bounds, risk tiers, and SOX controls. If your organization is putting AI into production, start by reviewing testing standards and change management policy. If neither one mentions model updates or behavioral bounds, they were written for a different kind of system.
At Trenegy, we help organizations navigate AI testing, deployment, and governance so AI delivers value quickly. To chat more about this, emailinfo@trenegy.com.
Trenegy is a non-traditional consulting firm based in Houston, Texas.
