Industries
What data does an IT managed service provider already generate for AI training?
Last updated /Seller intent
A managed service provider already writes down other people's outages. A user cannot print. A server disk fills. A mailbox rule loops. The technician tries a step, checks a result, escalates, and either closes the ticket or hands it to the client's vendor. Beside the queue, the provider keeps remediation runbooks it wrote for its own staff, and a professional-services tool records who was assigned, which step moved, and whether the issue returned. That is the operating record: ticketing, runbooks, and the workflow inside the PSA or RMM console. It is not the client's password vault, and it is not a recording of a remote session that shows the client's screen.
Say the exclusion first, because this trade trips it constantly. Client credentials, privileged access, RMM agent keys, firewall exports, VPN maps, and pasted secrets do not become training material because they were typed into a ticket to save time. They are access data. They stay out. A runbook that tells a technician how to diagnose a full disk without embedding a password can be a document the provider authored. A ticket that is only a pasted admin password and the word fixed is not a workflow. It is a leak the provider should not multiply. Commercial curiosity does not change that. This page is not legal advice, and it does not say an MSP may license its board.
Support records in general are how support tickets and chat logs can be licensed. Runbooks the provider wrote are how internal documents and playbooks can be licensed. Assignment and escalation history is a process trace, covered in how workflow and process records can be licensed. A license would still be a defined permission, as what AI data licensing means for a company explains. A software vendor's version of the tenant problem is what a SaaS company already generates that can train AI. An accounting firm's version of holding someone else's records is what an accounting firm already generates that can train AI.
Why the remediation path is the part a public KB does not have
Vendor documentation says how a product is supposed to fail. The MSP's ticket says how it failed at a real client and which check the technician ran before replacing anything. That path is scarce. It is also contaminated, because technicians paste the fastest proof: a config snippet with a key, a screenshot of an admin console, a remote-control recording. The path can sometimes be told without the proof. If it cannot, the ticket is not a candidate. We will not ask a provider to keep the secret in so the example feels complete.
PSA history adds the business of the provider: how work is triaged, which issues bounce, which runbook was attached, whether the same alert returned after the close. That is the provider's operation. The alert payload from the client's monitoring agent may include host names and user names the client did not agree to recirculate. Payload and path are different fields. Describe the path. Leave the payload until someone with authority, and counsel, says a specific slice is allowed. Do not start from the payload.
What an MSP can describe without handing over the keys
- Tickets that show the symptom in the provider's words, the checks the technician chose, and the outcome: fixed, waiting on the client, or handed to a vendor. The secret used during the fix is not part of the description.
- Runbooks and standard fixes the provider authored for its own team, with credentials and client-specific addresses removed or never present.
- PSA workflow: priority, assignment, escalation, reopen. The motion of the work, not the client's address book.
- A statement of which classes of issue the provider sees often, so a profile can be honest about repetition without listing client names.
Access data that is out of scope
- Passwords, keys, tokens, seed phrases, and one-time codes, wherever they were pasted.
- RMM agent installers, site keys, and remote-access recordings or screenshots that show a client's session.
- Firewall, VPN, and identity-provider exports whose purpose is to grant entry. A sentence that says a firewall rule was wrong can be a workflow. The rule export is access data.
- Client network diagrams and credential stores kept so the provider can log in. Convenience for the technician is not a training purpose.
What makes an MSP board a liability instead of a shelf
- A culture of pasting secrets into the ticket because the next shift needs them. That culture means the archive is contaminated. It is not a reason to license it faster.
- Remote-session recordings retained by default. They show whatever was on the client's screen, which can include people, mail, and finances the provider was not asked to republish.
- Runbooks that are a vendor's PDF with the provider's logo. Those may not be the provider's text to offer.
- Master service agreements that forbid reuse of client information, read as if they cover only the password vault and not the ticket that quoted it. The agreement may be wider. Counsel reads it. This site does not.
- A request to connect the RMM so the review can see live clients. Live access is the opposite of a profile. The free check does not need it.
How an MSP would be profiled
You are on a site operated by Unlockt, LLC, publishing as Big Data/Little Guy. We will not ask for a credential export, a screen recording, or an RMM login. The free check can ask whether tickets and runbooks exist and whether secrets are routinely inside them. If the honest answer is that the ticket is unusable without the secret, say so. That answer can end the shelf.
Where a description is still possible, it names issue classes, the presence of authored runbooks, and the credential exclusion in the same note. Buyers would see the note, not the board. Why legality is not a yes for every company applies with extra force here, because the provider holds access to other companies. What a data licensing agreement should cover would matter only after a scope existed that did not include access data. Many providers should never reach a draft. That is a sound result.
Questions people ask
Can an MSP license client passwords or RMM keys if the rest of the ticket is useful?
No. Credentials and access keys stay out. Usefulness of the surrounding ticket does not bring them in. If the ticket cannot be separated from the secret, the ticket stays out too.
Are remote-support recordings a dataset?
Treat them as excluded. They capture the client's screen. They are not a workflow export.
Do our runbooks count?
If the provider wrote them and they do not embed client secrets or a vendor's restricted text, they can be described. A purchased script the provider cannot re-license does not become theirs because they use it.
Is PSA history the client's contact list?
It should not be offered as one. Assignment and escalation can describe the provider's work. The client's user directory is a different object.
What if the master service agreement is silent?
Silence is not permission. Ask counsel before any client-related record is described as available. This page will not fill the silence with a yes.
How do we start?
Use the free check. Describe ticket classes and runbooks in words. Do not attach a board export, a recording, or a password list.
See what your data could be worth
Your company's data could be worth up to $5M+.
Potential licensing value varies by dataset, rights, quality, volume, buyer demand, and transaction terms. Estimates and examples are not guaranteed offers.
Check my data value