How to prepare company data for AI

What does AI-ready company data actually mean?#

AI-ready company data is a set of records that is findable, owned, permitted for the intended use, linked across systems, free of details that should not leave, and documented well enough for someone else to rely on. Formatting matters far less than those six properties.

Most companies prepare data for one of two purposes. The first is internal: a support assistant, a search tool over project files, or forecasting from order history. The second is external: licensing records to AI developers who use them to train or evaluate models. The steps overlap, but licensing raises the bar, because another party needs written evidence of rights and of how personal details were handled.

Licensing also changes who relies on the work. Records are licensed, not sold outright, so the company keeps ownership and sets the permitted use, but the preparation has to hold up for a reader outside the building.

The ten-step checklist#

The ten steps run roughly in order. Approvals are granted at the end, but the people who give them should be identified at the start.

• 1Step 1, inventory: list each system, the record families it holds and the years still exportable.
• 2Step 2, owners: name a business owner for every record family, not just a system administrator.
• 3Step 3, permissions: check customer contracts, vendor terms, employee notices and IP assignments.
• 4Step 4, retention: confirm what you are allowed or required to keep, and any legal holds.
• 5Step 5, history and exports: test how far back each export reaches and what it leaves out.
• 6Step 6, linking: keep the IDs that join a request to the work done and the outcome.
• 7Step 7, sensitive data: find personal details, credentials, client confidential material and HR content.
• 8Step 8, removal method: decide per field whether to exclude, redact, pseudonymize, generalize or keep.
• 9Step 9, documentation: write a data dictionary, a provenance note and a list of known gaps.
• 10Step 10, approvals: get sign-off from the authorized signer and any board, investor or lender consents.

Steps one to three: inventory, owners and permissions#

The first three steps establish what exists, who decides about it and whether the intended use is allowed. Skipping them is the most common reason AI data projects stall after a lot of cleanup has already been done.

Owners matter because system administrators can export data but cannot judge whether a use is appropriate. The head of support knows which customers have unusual contract terms; the quality manager knows which part numbers belong to a customer's proprietary design.

Steps four to six: retention, history and links#

Retention, history and linking decide how much of the record set is usable. Retention tells you what you may keep, history tells you how much you can still reach, and linking tells you whether the records explain anything.

Check retention schedules and legal holds before building any dataset, because records that should already have been deleted do not belong in a prepared set. Then test the exports. Many software plans limit how far back an export goes or leave out attachments, internal notes and audit history, so check your plan and the vendor's documentation rather than assuming the export is complete.

Linking is the most underrated step. A ticket on its own is a complaint; a ticket joined to the Jira issue, the code review, the release note and the customer's reply is a worked example of how a problem gets solved. Keep native IDs, ticket numbers, job numbers and order numbers through every export so those joins survive.

Steps seven and eight: find sensitive data and decide how to remove it#

Sensitive data in operational records mostly hides in free text, not in labeled fields. Names, phone numbers and addresses appear inside ticket bodies and dispatch notes; passwords and API keys get pasted into tickets and committed to code; HR matters surface in chat channels and email threads.

Automated tools help with the first pass. Presidio, an open-source PII detection SDK now governed by the community under the Data Privacy Stack organization, combines entity recognition, patterns and rules, yet its own documentation warns that there is no guarantee it will find all sensitive information. Secret scanners such as gitleaks and TruffleHog look for passwords, API keys and tokens in git repositories and other sources. Treat their output as a starting point and review samples by hand.

Pseudonymized data may still count as personal data under some privacy laws, so a consistent token is not a shortcut around the privacy review.

Steps nine and ten: documentation and approvals#

Documentation turns a folder of exports into something another team can rely on. A short data dictionary, a provenance note that says which system and export produced each file, and an honest list of known gaps answer most questions before they are asked.

Approvals close the checklist. Identify the authorized signer early, check whether the board, investors or lenders must consent to licensing company records, and record each approval in writing. Internal AI projects need lighter approvals, but a short sign-off from the data owner still helps when an auditor later asks what a model was fed.

Which preparation mistakes cost the most time?#

The most expensive preparation mistake is cleaning records before anyone has checked whether they may be used. Weeks of redaction on a record family that a customer contract or vendor term rules out cannot be recovered.

The other costly mistakes are quieter and show up only when someone tries to use the result.

• 1Exporting flat tables: a CSV of ticket fields without internal notes, attachments or the linked issue ID loses the part that explains the work.
• 2Trusting one automated pass: detection tools miss names in odd formats, signatures in scanned files and secrets pasted mid-sentence.
• 3Preparing everything at once: one well-documented record family is more useful than ten half-finished ones.
• 4Losing the export trail: nobody recorded which system, date range or query produced a file, so it cannot be refreshed or defended.
• 5Leaving approvals to the end: a lender or investor consent discovered after preparation can delay or narrow the whole project.

Illustrative: a property management software company prepares one archive for two uses#

Illustrative: a fictional property management software vendor wants an internal support assistant and is also curious whether its records could be licensed. Its CTO inventories Zendesk, Jira, GitHub, Confluence and Slack, and names the head of support, the VP of engineering and the controller as owners.

The review finds tenant names and phone numbers in ticket bodies, several API keys pasted into old tickets, and an HR channel in Slack that has to be excluded. Ticket-to-issue links exist for most product bugs, so the team keeps those IDs through the export. Counsel confirms that customer contracts allow internal use but flags a clause on customer communications that requires de-identification before any outside license.

The company prepares one redacted archive with a data dictionary, uses it for the internal assistant, and runs a separate rights review before considering any external license. One preparation effort serves both decisions.

How SourceX approaches preparation for licensing#

SourceX orders the work so that effort follows rights. In the SourceX five-step transaction (Supply, Rights, Preparation, Approval and Delivery), preparation comes after the rights review, so nothing is cleaned that cannot be licensed. Preparation removes personal and confidential details, and the supplier reviews and approves the prepared result before anything is released.

The privacy record in the SourceX Evidence Packet describes what was removed and how, which is the document an outside licensee will ask for. The initial fit check collects metadata only, and nothing is shared during that assessment.