How to prepare company data for AI, starting with the files you already have

Data is ready for a purpose, never in general. The same project archive can be ready for "find every drawing issued to this contractor" and hopeless for "estimate the steel tonnage of the next tower."

For the purpose you pick, ready means five things:

• Findable: the tool can reach it, and it doesn't live on one person's laptop.
• Consistent: the same thing is named, dated and measured the same way everywhere.
• Current: superseded versions are marked, so answers don't come from an old revision.
• Owned: someone is responsible for it being right, and can say when it isn't.
• Permitted: it's clear what the tool may read, and what it must not.

In IBM's study of chief data officers, only 26% were confident their data could support new AI-enabled revenue streams. The gap is rarely the model. It's this list.

The most expensive way to prepare data for AI is to try to prepare all of it. Cleaning every folder in the office is a project with no end and no test of success.

Pick one question the office asks repeatedly and answers slowly. Which of our past projects had a similar structural system? What did our past hospital fit-outs cost? Which rooms in this model still have no finish?

A good first question has three properties: it comes up every week, the answer already exists somewhere in the office's own files, and someone in the office can tell a right answer from a wrong one.

Then work backwards: which files hold the answer, who can say whether they're right, and what a correct answer looks like. That last part is the success test, and it has to exist before anything is built. The same rule runs through our research and development work: the measure comes before the build.

In a generic company, data lives in a CRM and an accounting system. In an AEC office, the most valuable data lives in files built for drawing, not for reading:

• Revit models, holding room areas, element types, quantities and parameters, when they're filled in.
• CAD and PDF drawing sets, where information is visible to a person and mostly unreadable to a program.
• Spreadsheets: estimates, schedules exported from models, and trackers kept by one person.
• Email and messaging, where decisions were actually made and never written down anywhere else.
• Accounting and timesheet systems, which know what a project cost but not what it contained.

For each source, write down where it lives, who owns it and how a program could read it. That list is the first real output of any AI readiness assessment, and usually the first time an office sees all its sources in one place. Scattered data has a documented price: NIST estimated the cost of inadequate interoperability in the US capital facilities industry at $15.8 billion for 2002, and called that figure likely conservative.

Generic guides assume tables. AEC data is mostly files, and a file's name and folder are its metadata. A drawing called "plan-final-v2-NEW" tells a person little and a program nothing.

Before any AI reads a project archive, three things need a rule: how files are named, where each kind of file lives, and how a superseded version is marked. Standards such as ISO 19650 give a naming structure to start from. The point is to pick one and apply it, not to adopt every field a standard offers.

The version rule matters most. A tool answering from a superseded revision gives a confident, well-written, wrong answer. That's worse than no answer, because nobody checks a confident one.

A Revit model is a database nobody treats as one. Room areas, wall types, door counts and finish data are all in there, but only as good as the parameters people actually filled in.

Two steps make it usable. First, check that the parameters the question depends on are filled in and consistent, which is exactly what a Revit model checker checkset is for. Second, extract them into tables a program can read, regularly rather than once. Exporting a Revit schedule to Excel is the manual version of that step.

Drawing sets are harder. Text in a PDF can be extracted; the meaning of a line on a plan mostly can't. If a question depends on information that only exists as drawn geometry, the honest answer is that the data needs converting before it's ready.

The other half of an office's knowledge sits in documents: specifications, design reports, meeting minutes, RFIs and the email around them. This is the data most AI assistants get pointed at first, and the data least prepared for it.

In the same IBM study, only 26% of chief data officers were confident their organization could use unstructured data in a way that delivers business value. For a document archive, preparation comes down to four things:

• Text, not pictures of text: a scanned PDF needs text recognition before anything can search it.
• One current version: drafts and superseded issues removed or clearly marked.
• Basic tags: project, date, discipline and status on every document, in the file name or alongside it.
• A boundary: the folders the assistant may search, decided per project.

An assistant that searches every draft of every report answers from whichever version it found first.

Cleaning is the unglamorous middle: fixing units, dates, names and duplicates so that one thing is recorded one way.

Persian-language offices have a problem most guides never mention. A client name typed with the Arabic forms of ye and kaf in one file and the Persian forms in another is two different strings to a program. So is a date in Persian digits next to one in Latin digits, or a Jalali date next to a Gregorian one. A person reads them as the same thing. A search or a model doesn't.

Duplicates are the other half. One project stored under several names, or one consultant under two spellings, splits every answer into pieces. Merge them once, then add a rule at the point of entry so they don't come back.

Units and definitions are the engineering version of the same problem. Net area in one table and gross area including walls in another are both called "area" and are not the same number. Any column that could mean two things should carry its definition next to its name.

Every dataset needs an owner: a named person responsible for it being right, who gets told when it isn't. Without one, cleaned data drifts back to its old state the moment the next deadline arrives.

Access is the other decision. Contracts, fees, personal data and client-confidential drawings may be exactly what a question needs and exactly what a tool must not read. Write down what's in and what's out before connecting anything. NIST's AI Risk Management Framework is a useful, voluntary reference for working through those risks.

Ownership also needs a way to report errors. When the tool gives a wrong answer, the path from "this is wrong" to the file that caused it should be short. If nobody can trace an answer back to its source, nobody can fix the source.

A useful assessment is short and ends in a decision. It should produce:

1. The one question, and what a correct answer looks like.
2. The sources that hold the answer, with an owner for each.
3. A sample check of those sources: how much is filled in, consistent and current.
4. The access rules: what may be read and what may not.
5. A verdict: ready, ready after a named clean-up, or not worth doing.

The third verdict is a real outcome. If the question can be answered by a report or a filtered schedule, it doesn't need AI, and nobody should sell you any, including us. If the data behind it can't be made consistent at a reasonable cost, the honest result is to stop there.

A one-off clean-up stays ready for about as long as nobody touches the files. Data stays ready when the rules are enforced where data is created: a naming check on save, a required parameter in the model check, a dropdown instead of free text.

Extraction should run on its own too, regularly, into one source of truth per dataset, as covered in where AEC workflow automation should start. At that point AI is one more reader of data the office already trusts, and that's the only point at which it becomes an advantage.

Once a tool is running, the test is the one written at the start: does it answer the chosen question correctly, from current sources? Check a sample of answers against the files every month, and keep a record of the wrong ones.

Every wrong answer traces back to one of three causes: missing data, inconsistent data, or data it shouldn't have read. By then each source has an owner, which is exactly why the owners were named first.