Consulting and recruiting
IT consulting and systems integrators: delivery records and AI value
By SourceX Editorial · Updated
Short answer
An IT consulting firm's most valuable data for AI is its delivery history: implementation tickets, configuration decisions, cutover runbooks, test scripts and support fixes linked to outcomes. Ownership decides scope. Records of how your team worked are often yours to license, while code, configurations and data built for or supplied by clients usually belong to those clients.
Key takeaways
- Systems integrators hold linked delivery records showing how real enterprise systems are configured, tested and fixed.
- Client code and client-specific configurations are usually owned by the client and excluded from any license.
- Internal runbooks, firm-built accelerators and de-identified ticket histories are the records most often in scope.
- Tickets and repositories must be scanned for credentials and client data before anyone reviews them.
- Partner agreements with software vendors can add restrictions of their own.
What delivery records do IT consulting firms hold?#
IT consulting firms and systems integrators hold delivery records spanning the full life of an implementation: statements of work, design decisions, configuration workbooks, build tickets, test scripts, cutover plans and the support tickets that follow go-live. Most of it lives in Jira or Azure DevOps, Confluence or SharePoint, Git repositories and a PSA or time-tracking system.
What makes these records unusual is repetition. An integrator that has implemented the same ERP, CRM or cloud platform many times holds a comparative history of how different organizations made the same decisions, and what broke when they did.
Which records matter, and who usually owns them?#
The records that matter most are the ones that tie a task to a decision and a result, and ownership varies sharply between them. The ownership column below is a starting point, not a conclusion: many MSAs assign deliverables to the client while letting the firm keep pre-existing materials, general know-how and its own tools.
| Record | Where it lives | Usual owner | AI value |
|---|---|---|---|
| Implementation tickets | Jira, Azure DevOps | The firm's record of its work, often with client content inside | Task sequences, troubleshooting steps, resolutions |
| Configuration workbooks and design documents | Confluence, SharePoint | Frequently a client deliverable | Decisions and trade-offs, once client details are removed |
| Runbooks and cutover plans | Confluence, shared drives | Firm templates; client versions may be deliverables | Step-by-step operating procedures |
| Test scripts and defect logs | Test tools, Jira | Mixed | Expected versus actual behavior, with fixes |
| Custom code and integrations | Git repositories | Usually the client under the MSA or SOW | High, but rarely licensable |
| Internal accelerators and tools | Firm repositories | The firm, if built outside client engagements | Reusable patterns and templates |
| Time and staffing records | PSA, timesheets | The firm | Effort by task type and project phase |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why client code usually stays out#
Client code usually stays out because most consulting agreements assign custom development to the client once it is paid for. Even where the firm wrote every line, the client typically owns the result, and the firm's rights are limited to what the contract reserves.
Copyright's work-made-for-hire rule does not change that. Code your employees write within the scope of their jobs is the firm's work for hire, but ownership then passes under whatever assignment the client contract contains. Code written by subcontractors needs its own written assignment to the firm, because commissioned work counts as made for hire only in listed categories and under a signed agreement.
Treat client repositories, client-specific scripts and integration code as excluded unless counsel finds an express right to reuse them. The same applies to configuration exports that reveal a client's business rules, pricing logic or approval chains.
Why AI developers value implementation records#
AI developers value implementation records because they show skilled people operating complex enterprise software step by step. Agents that configure systems, triage tickets or follow runbooks need examples of real tasks, the reasoning behind them and whether they worked.
A ticket that records a failed data migration, the diagnosis and the fix is the kind of multi-step, outcome-labeled record that is hard to produce synthetically. Runbooks add the procedural layer, and defect logs capture the gap between how a system should behave and how it actually did.
The value also sits in breadth. Records drawn from many client environments show how the same platform behaves under different data volumes, integrations and business rules, a range that a single in-house IT team rarely sees.
Which practices produce the strongest records?#
The practices that produce the strongest records are those where the same kind of system is implemented repeatedly and every issue is ticketed. Each practice also has its own typical contamination, which decides how much cleaning a package needs and whether some engagements should be left out altogether.
Security work is the clearest case for caution. Findings from penetration tests and assessments describe a named client's weaknesses, so most firms treat them as excluded regardless of contract wording.
| Practice | Strongest records | Watch for |
|---|---|---|
| ERP and finance systems | Configuration decisions, data migration tickets, cutover runbooks | Client ledger data and vendor lists in sample files |
| CRM and service platforms | Workflow designs, automation rules, support escalations | Customer contact data copied into test records |
| Cloud migration and infrastructure | Runbooks, infrastructure templates, incident tickets | Credentials, network diagrams, client architecture |
| Data and analytics | Pipeline tickets, data model decisions, quality fixes | Client datasets attached to tickets |
| Security consulting | Firm-written methodology and checklists | Client findings and vulnerabilities, usually excluded |
What to clean before anyone reviews the records#
Delivery records need cleaning for secrets and client data before anyone reviews them, because tickets and repositories collect both. Engineers paste connection strings, API keys, screenshots of production screens and sample customer files into tickets while troubleshooting.
Automated scanning catches patterns; it does not judge context. Plan for someone with delivery experience to review samples from each engagement type and confirm that what remains describes the work rather than the client.
- Scan repositories and ticket exports for secrets with tools such as gitleaks (now maintained with security patches only) or TruffleHog, which also scans chats and wikis; TruffleHog's live verification logs in with found credentials, so run it with care.
- Remove attachments holding client data samples, screenshots or exports.
- Replace client names, hostnames, environment names and tenant identifiers.
- Exclude tickets from engagements whose contracts prohibit reuse.
- Strip the names of client staff from comments, watchers and assignees.
- Keep the internal structure: ticket type, status history, linked fixes and resolution notes.
Illustrative: an ERP implementation partner sorts its archive#
Illustrative: a fictional ERP implementation partner has delivered mid-market finance and supply chain projects for years, with tickets in Jira, design documents and runbooks in Confluence, and integration code in GitLab. Its managing partner wants to know which of these records could support an AI data license.
Counsel's review of the standard MSA shows that custom code and client-specific configuration documents are client deliverables, while the firm keeps its methodology, templates and pre-existing tools. The firm excludes every client repository and configuration workbook. It proposes its internal runbook library, accelerator code built outside engagements, and de-identified build and support tickets from engagements whose contracts allow anonymized reuse.
How SourceX approaches IT services records#
SourceX treats an integrator's archive as several possible packages rather than one, sorted engagement by engagement in the Rights step of the SourceX five-step transaction, which runs Supply, Rights, Preparation, Approval and Delivery. Client ownership, vendor partner terms and any reuse restrictions are settled there, before preparation work is spent on records that cannot be licensed.
Each package that goes ahead gets a SourceX Evidence Packet: where the tickets and runbooks came from, the firm's right to license them, the uses permitted, how client and staff details were removed, and who signed off on release. Repositories and ticket archives remain in the firm's own environment until the firm approves delivery.
Frequently asked questions
Do software vendor partner agreements affect what we can license?
They can. Partner programs often carry confidentiality terms over vendor training materials, roadmaps and support content, and some restrict use of vendor documentation. Review partner agreements alongside client contracts, and keep vendor-confidential material out of any package.
Are timesheets and PSA records useful?
Sometimes, as context. Time entries by task type and project phase show how effort is spent across implementations. On their own they carry limited signal, and they include staff names and rates, which are removed or generalized before any review.
Does licensing our internal accelerators put our IP at risk?
It can if done carelessly. Under the federal trade secret definition in 18 U.S.C. 1839(3), information is protected only if its owner takes reasonable measures to keep it secret. A license with strict confidentiality, permitted-use and no-redistribution terms helps preserve that position; broad, unrestricted release can undermine it.
What about managed services tickets after go-live?
Managed services and support tickets are often the strongest records, because they link an issue to a diagnosis and a fix over time. The same ownership and client data checks apply. Firms that also run managed services should treat those tickets as a separate record family with its own contract review.
Can we use records from a client that no longer exists?
A client closing does not automatically release its rights. Confidentiality obligations may survive, and the client's assets, including its IP, may have passed to an acquirer or a trustee. Counsel should confirm the position before any of those records are included.
Sources
- A work made for hire arises when an employee creates the work within regular duties, or when a work in certain statutory categories is specially commissioned under an express written agreement. Source
- 17 U.S.C. 201(b) provides that for a work made for hire the employer is considered the author and owns all rights unless the parties agree otherwise in a signed writing. Source
- Gitleaks is an MIT-licensed tool for detecting secrets such as passwords, API keys and tokens in git repositories, files and stdin. Source
- TruffleHog is an open-source secret scanner that scans sources including Git, chats, wikis, logs, object stores and filesystems. Source
- Under 18 U.S.C. 1839(3), information qualifies as a trade secret only if the owner has taken reasonable measures to keep it secret and it derives independent economic value from not being generally known. Source
Related resources
- InsightMaintenance-mode software products: what their engineering histories hold
- InsightRecords written with AI assistance: do they lose value for licensing?
- InsightAI disruption and software valuations in 2026: does proprietary data help?
- IndustryBPO & contact centers data
- IndustryFintech software data
- QuestionCan SaaS data be licensed?
See if your company qualifies
A short company assessment. No data uploads are needed.