Last updated: November 10, 2026
Contract engineers arrive with their own AI subscriptions, so decide before day one which tools are approved, which data classes never get pasted, who owns AI output, and how AI-written code is disclosed. Put it in the contract and the onboarding, then check through tool logs, not surveillance. The National Bureau of Economic Research found in 2026 that 78% of firms use AI, so assume your contractors do too.
Picture a contract engineer on day one. Laptop, badge, Jira login. They open the chat window they have used for two years and paste in a stack trace from your billing service. Nobody did anything wrong. Nobody told them anything at all.
Your employees went through some version of an acceptable use review. The contractor went through a statement of work. Most of the damage I see here is not a technology problem. It is a clarity problem, and a fixable one.
I write in partnership with KORE1, which places contract engineers, so yes, I want you to hire them. I also want you to hire them into a written policy. The regulated industry software engineers KORE1 places are used to working under rules, and they do better when the rules exist.
Why Do Contractors Need Their Own AI Tool Policy?
A contractor AI tool policy is a short written rule set that tells outside engineers which AI coding tools they may use on your systems, which data classes they may never paste into any of them, who owns what the tools produce, and how AI-assisted code is flagged in review.
Your employee AI policy probably stops at the badge reader. Contractors work from devices you may not own, on accounts you never bought, with settings you cannot see. Call that shadow AI, which just means tools nobody approved and nobody is watching. On a contract team it is the default case. It is load-bearing spaghetti. Nobody planned it. It just grew until the sprint depended on it, and now nobody wants to touch it.
How common is the underlying habit? The NBER survey reached nearly 9,000 CFOs, CEOs and senior executives in seven countries in summer 2026. It found 78% of firms use AI and 80% of the executives use it themselves, about 2.1 hours a week. The same paper puts the productivity gain at 0.2% a year so far, which the authors call modest. Modest upside. The downside of a leaked repository is not modest, and that asymmetry is the whole argument for writing the thing down.
Run my Clarity Stack over a typical contractor engagement and all three layers fail at once, because nobody has defined what compliant AI use looks like, the rules (if they exist) sit in a wiki page the contractor was never pointed to, and decisions get made one chat window at a time, which is the hallway conversation of 2026.
Devin Hornick, a partner at KORE1, described who now shows up to contractor conversations: “With AI, I’m seeing that so many more managers are involved… HR kind of ran things. HR’s there and… they just sit there on the calls now.” I read that as a warning. The person deciding how an outside engineer uses AI is now a hiring manager with a deadline, and what they decide, they decide without a template.
Why not ban it and move on? Because engineers who cannot get an answer stop asking permission and start asking forgiveness, and a ban moves the use off your logs and into a personal account where you will never see it. I have watched good people make that trade on a deadline. Tell them yes, to these tools, under these settings, and most of them will take the yes.
Which Tools and Accounts Are Approved?
Start with the account. The same product behaves differently on a seat you provision and on a subscription the contractor pays for, because retention, whether your code can train anyone’s model, who sees the admin logs and who can export the history are all properties of the plan, and you only control the plans you hold.
Call it build vs buy in miniature. Buy the seat and you get logs, settings and a revoke button for the last day. Let them bring their own and your cost is zero. Your risk has no size you can name.
- A seat you provision, on your tenant, behind your single sign-on, which is the default for anything above public data and dies with the contract.
- The contractor’s own enterprise account, through their employer. Acceptable once someone on your side has read the plan terms and written the training and retention settings into the engagement.
- A personal consumer subscription gets public data only, if you allow it at all, and the history belongs to them.
- Self-hosted or local models are fine in principle, though somebody still has to say where the weights and the prompt history live and who can read them.
Write the approved list as categories and settings, never product names, because it goes stale the next time a vendor renames a plan, and review it every quarter. Then put it in the packet with the contractor onboarding checklist, because the first paste happens on day one, not day eight.
Which Data Can Be Pasted Into an AI Tool?
Sort by the damage if it leaks, the way NIST’s FIPS 199 does with low, moderate and high impact. You do not need federal paperwork to borrow the idea. You need buckets that a new contractor can recite from memory by Tuesday, and that a reviewer can apply to a diff in about ten seconds.
| Data class | Company-provisioned seat | Personal subscription |
|---|---|---|
| Public documentation, open-source code, vendor docs | May paste | May paste |
| Your internal code with no sensitive logic: tests, UI, build tooling | May paste | Never |
| Core proprietary logic: pricing, underwriting, scoring, fraud rules | Repo owner approves, case by case | Never |
| Customer nonpublic personal information, including masked extracts that can be re-identified | Never. Use synthetic data | Never |
| Credentials, API keys, tokens, connection strings | Never | Never |
| Production logs and data extracts | Only after scrubbing, on an approved seat | Never |
| Regulator correspondence, exam findings, confidential supervisory information | Never | Never |
| Penetration test reports and unpatched vulnerability details | Never | Never |
| Third-party code or client material under NDA | Only if the NDA allows it | Never |
These are my defaults, a starting point for your own risk assessment and not a regulator’s list, so let your counsel and security lead change them. Two rows surprise people. Masked extracts that a determined person can reverse are not masked, and an exam finding sitting in a chat history is a document you never meant to circulate.
Contract engineers who work inside your AI policy.
Send the team your roles, approved tools, compliance regime and a start date through the contract engineering team page, and we will match engineers against them before anyone is submitted.
Does Your IP Clause Cover AI Output?
Not legal advice, and your counsel gets the last word. I can tell you where the problem sits.
A contractor owns the code they write until a signed agreement moves it to you, which Robert Ardell walks through in who owns contractor code, and the assignment language that does the moving is covered in contractor IP ownership agreements. Neither was written with a code assistant in the room.
The wrinkle is what an assignment can hand over. The U.S. Copyright Office’s January 2025 report on copyrightability concluded that copyright does not extend to purely AI-generated material, that prompts alone do not provide sufficient control, and that using AI to assist rather than stand in for human creativity does not affect protection for the output. Your clause can transfer whatever the contractor owns. If a large block of the deliverable is machine output with little human authorship, there may be less there than you think.
So the clause needs four additions. Define deliverables to include AI-assisted work, so nobody argues later about what counts. Have the contractor warrant that the plan terms of any tool they use give the vendor no rights in the output and demand no attribution. Make them tell you when a tool flags a suggestion as matching public code. Last, keep the disclosure record from the next section, since it doubles as your evidence of who wrote what.
How Should AI-Written Code Be Disclosed?
In the pull request, every time, with a checkbox. AI-assisted code is fine. Undeclared AI-assisted code is the violation, and that distinction is the entire policy in one line.
I have laid out the review side in AI code review for engineering teams, and the short version is that review tiers follow risk, not authorship. Disclosure is what makes the tiers work for contractors. A declared generated block on a trust boundary goes to your senior reviewer, while the same block undeclared sails through as ordinary code, because nobody knew to look.
AI assistance in this change [ ] None [ ] Suggestions accepted (autocomplete, small edits) [ ] Generated blocks (whole functions, files, or tests) Tool category: company seat / contractor enterprise account / other I read every generated line and can explain it: [ ]
That is the whole template. Drop it into the repository’s pull request template so the contractor cannot open a PR without seeing it, and pair it with your contractor code review checklist so the reviewer knows what to ask.
How Do You Check Without Spying?
Check the systems, not the person. You get seat-usage logs from the admin console, egress rules that keep personal AI domains out of the development environment, secret scanning before every commit, and a weekly sample of pull requests read against their disclosure boxes. That is enough.
Show me the data, as I say too often. Pull the usage log for week two. A contractor holding a seat with zero activity, whose pull requests carry heavy generated blocks, is a short conversation you need to have. A log and a set of flags that agree need nothing from you, which is the point.
Screen capture and keystroke logging are something else entirely. They tell contractors you assume the worst, and the good ones leave. Say exactly what you log in the engagement paperwork, and hold employees to the same standard, because a control that watches only the outside engineers builds the two-tier culture you were trying to avoid. Notice requirements for monitoring vary by state, so ask counsel before you switch anything on.
Where the contractor uses a laptop you do not own, move the work to the tool instead of the tool to the laptop. A virtual desktop or cloud development environment, with the approved assistant inside it and the personal one unable to reach it. The access tiers in my contractor access policy template assume exactly that setup.
What Breaks If Regulated Code or Data Leaves the Building?
More than the code. For a lender, a fintech or an insurer, a paste is a disclosure event first and a security question second, and the paperwork follows the first one.
The FTC’s Safeguards Rule, which covers non-bank lenders and many fintechs, makes you identify and manage the data, personnel, devices and systems that touch customer information, and to monitor and log what authorized users do with it. A personal chat history is a system you never identified, holding data you cannot log. When an examiner or an auditor asks where a borrower’s record went, “a contractor’s account” is not an answer you can show evidence for.
Then the cleanup arrives. Any key that appeared in a prompt gets rotated, the extract gets traced to every person who saw it, and somebody on your side decides whether notification duties apply. One pasted production extract turns into a week of work for people who were supposed to be shipping, and I would rather you spent that week on the policy. The access side of this lives in contractor access to borrower and policyholder data.
What Happens to AI Tool History When the Contract Ends?
It walks out with the contractor unless you say otherwise. Most offboarding checklists remove the badge, the repository access and the email account. None of those hold the chat history.
Over a thirteen-week engagement an assistant quietly accumulates conversation history, project memory and custom instructions about your codebase, indexed repositories, connectors with live tokens, local caches, and the odd generated script the contractor parked somewhere personal for later. Take inventory of all of it.
- Revoke the seat the day the contract ends, after you export the logs your retention schedule requires.
- Rotate any secret that ever appeared in a prompt, and let your secret scanner and egress logs tell you which ones.
- Move the rules files, saved prompts and project instructions that worked into the repository. They are team assets, and they should not live in one person’s account.
- Have the contractor attest in writing that histories touching your code in personal accounts are deleted. I will be plain about this one. You cannot verify deletion in an account you do not control, so the attestation is a contract term and not a control, and the real control is keeping your code out of personal accounts to begin with.
Add these four lines to your contractor access offboarding checklist and the last day stops being the weak point.
From KORE1: how we source, vet, and place these contractors
KORE1 has recruited technology talent since 2005 and averages 17 days to fill IT roles, with 92 percent of hires still in the job twelve months later. The model in this post assumes contract engineers who have worked under real controls, so the software seats come through our regulated industry software engineer staffing desk and lending and payments seats come through mortgage tech and fintech engineering staffing. Send your approved-tool list and data-class table with the requisition and we put them in front of candidates at the first screen, so you learn in the recruiter stage whether someone can work inside your policy, not in week two.
Contractors are W2 employees of KORE1, billed to you hourly and paid every Friday, and they can convert to your payroll at no fee after 1,040 hours.
Questions Engineering Leaders Ask About Contractor AI Use
Can contract developers use their own AI coding tools on our codebase?
Only the ones your policy names, and only on accounts you can see into. Your code goes through a company seat or an approved enterprise account. A personal subscription gets public data at most, and only after someone has read its retention and training terms.
Does a contractor need a different AI policy than an employee?
Same rules, different enforcement. The data classes and review standards should be identical for both. What changes is the device, the account and the end date, which is why contractors get a company seat, a scoped environment and an offboarding step that employees handle through HR.
What counts as shadow AI on a contract team?
Any AI tool touching your code that you did not approve and cannot see. Think personal subscriptions, browser extensions, and assistants running on a laptop you do not own. You find it in egress logs, secret scans and the pull request disclosure box, rarely in a survey.
How do you review AI-generated code from a contractor?
Like anyone’s code, with the disclosure flag deciding how hard you look. Declared generated blocks go to the review tier their risk calls for, using the tiers in my AI code review piece. An undeclared block found later is a policy breach, and the code itself is a separate question.
We have no engineering team. Who can help write an AI policy for our staff?
Three people. A lawyer for the clauses, whoever runs security for the data rules, and one owner for the policy after launch. Most companies skip the third and then wonder why the document is two years old. A contract AI governance lead can hold it for a quarter while you build the habit, and the data-class table above is a workable first draft.
Write It Down Before Monday
Every engagement I have watched go sideways on AI had the same root. The rule lived in somebody’s head, and the contractor was not in the room. The good ones had a one-page list, a table like the one above and a pull request box. That is the whole system. It takes an afternoon.
If you are staffing a regulated codebase and want contract engineers who already work this way, talk to the KORE1 team. And if you want a second set of eyes on your draft policy, connect with me on LinkedIn.
As of November 2026. The NBER figures reflect the paper’s October 2026 revision, and this post is reviewed every six months. It is general information and not legal advice.
