Data pros share their non-negotiable governance standards

How is maintaining data standards like listening to a server recite the specials at a fancy restaurant? Sometimes you get more information than you need.

That happens in Kyle McCluskey’s line of work as a lead AI solutions engineer at business-strategy partner TXI. Recently, McCluskey helped a railcar leasing company comb through a mountain of repair-related report data—3 million records—so that employees could gain AI-powered insights for questions like: How much should this job cost? And, who should pay for it?

Even structured data sets like railway service forms and specific jobs like a ladder replacement—with established codes and fields—can be the “wild west,” according to TXI CEO Mark Rickmeier; some codes entered by repairers, for example, are inaccurate.

“What was the invoice? Where did the shop come from? Who is the person that did it? That’s all kind of noise that doesn’t help our model,” McCluskey told IT Brew.

Maintaining data standards is an essential task as AI agents make rapid, enterprise-impacting decisions; inaccurate or missing data could lead to distorted decisions, reduced trust among data teams, and compliance risks, according to an early 2026 report from IBM.

IT sheriffs like McCluskey shared their non-negotiable standards, along with how they provide order to a large data set. They also shared the best ways to enforce those standards.

A data to-do list. Sue Bergamo, general partner and CISO at AI risk and security company Cyber Scale, has a list of non-negotiable data-governance standards:

• Identity and ownership: Who makes decisions on CRM or ERP data—and which data should be ingested by an AI model? Name clear data owners, by application, who can ensure that data cataloging is up to date and privilege rights are set.
• Data structure: That includes tags so that data can be quickly extracted.
• Access and privileges: Access should be least privilege and based on role.
• Lineage and traceability: Define where the data came from, and its stops along the way.
• Data retention. Have a clear understanding of what data (say, financial records) needs to be deleted and when.

A governance, risk, and compliance (GRC) team can help enforce these standards, which often demonstrates a company meets particular frameworks, according to Bergamo. Meanwhile, data engineers should automate rules programmatically where possible, like enacting access and retention restrictions.

Lauren Murphy, founder at data affairs company Friday Initiatives, sees automation as an excellent standard enforcer.

“Our view on data retention and deletion is that if it’s a manual process, it’s never going to get done,” she said. “I don’t know anyone who, on a Friday, goes through and deletes their emails that are no longer necessary, or deletes the documents that are no longer necessary.”

Business sense. For Murphy, standards and classifications only work when they’re tied to a specific business objective, like a payroll task or fraud prevention, rather than a blanket label like “PII.” (PII refers to “personally identifiable information,” and tagging it all might waste time if the sensitive data is not classified for a reason, Murphy told us.)

“We use purposes as our classifications,” Murphy said, adding that her team figures out: This is what we want the data for.

With clients, McCluskey seeks a deep, pragmatic understanding of the data source. In the case of railway cars, it’s:

• Non-negotiable items required on a maintenance order
• Expected ranges and exceptions for data fields

To achieve that understanding requires in-depth, face-to-face conversations. “Your users get that knowledge by doing the actual work. As an engineer you get that knowledge by talking to your users,” McCluskey wrote in a follow-up email to IT Brew.

And the data engineering choices flow from there: These fields, in this structure, with these allowed values, represent how we choose to run our business.

“You can’t get around having to think of and understand your business. You need to have a point of view and an opinion. We can codify that,” he said. “Then we’re cooking with gas.”

Collaborating with business leaders, McCluskey and his team zeroed in on three fields to achieve the necessary insights: a description of the event, a job code (after verifying that the description matched the job code), and the reason for the report (which reveals cost allocation).

McCluskey subscribes to the “YAGNI” approach: You aren’t gonna need it. A slim data set keeps the model from getting confused. “The time that you spend on understanding your problem is going to get paid back tenfold,” he said.

Here’s what McCluskey enforces, broadly, on his AI jobs:

• Formalize that narrow schema of allowed values
• Build pipelines that validate against those standards
• Quarantine data that doesn’t fit the established schema

For data that doesn’t fit assigned standards, McCluskey encourages a carrot over stick approach. Convincing a company that accurate job codes could reduce costs and make a business more effective beats giving someone a lecture about the abstract principles of good data governance, for example.

And the funny thing about standards: They can change as you better understand your three million records. (Repair reason, for example, was a late addition to McCluskey’s railway data pipeline.)

“You have to have a structure,” McCluskey said. “We also want to be able to evolve that, because software, because humans, we always change.”