Tell the client that a named firm will do engineering under your contract before the work starts, whenever any of three things is true. The contract already asks. A security questionnaire would force you to lie if you stayed silent. Or you are about to put your own name on a system in a jurisdiction that treats that name as you becoming the provider. White-label means the client buys from you, is invoiced by you, and gets technical answers from you. It does not mean the existence of the firm is a secret you can keep once someone with a right to ask has asked. Day to day, the engineers still do not need to be introduced. The legal entity does need to be nameable.
Agencies treat those as the same decision, and they are not. Hiding the partner's brand from a kickoff with twelve stakeholders is ordinary commercial sense. Hiding the partner's existence from the person who signed your master services agreement, or from the reviewer who will ask whether any third party can see production data, is a different act. One protects the relationship you sold. The other bets that nobody with a duty to look will look. The bet is getting worse, not better, because the questionnaires have started to assume a supply chain whether or not your proposal mentioned one.
The cleanest published statement of what a name does is not a vendor's slide. Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, says that any distributor, importer, deployer or other third party "shall be considered to be a provider of a high-risk AI system" and "shall be subject to the obligations of the provider under Article 16" in any of three circumstances. The first is the one an agency principal should read twice: "they put their name or trademark on a high-risk AI system already placed on the market or put into service, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated" (European Union, Regulation (EU) 2024/1689, Article 25(1)(a), Official Journal L 2024/1689, 12 July 2024). Putting the mark on the system moves the provider duties. A contract can allocate those duties somewhere else. Silence is not an allocation.
Read the limit before you treat that sentence as your MSA. It applies to high-risk AI systems as that regulation defines them, not to every chatbot an American agency white-labels for a client who will never place anything on the Union market. The other two triggers in the same paragraph are a substantial modification that keeps the system high-risk, and a change of intended purpose that makes a system high-risk. Most agency delivery is none of those three. This is not legal advice, and a blog post is the wrong place to decide whether a particular build is high-risk. Take the clause to your counsel. The structure is still the useful part, because it is the structure your client's counsel will eventually use even when the statute in front of them is a different one: a name on the system moves obligations, and the only thing that moves them back is writing.
The same article says what the writing has to contain. The provider and "the third party that supplies an AI system, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance" needed for the provider to comply, based on the generally acknowledged state of the art. Open-source components made available to the public under a free licence are carved out, other than general-purpose AI models. Again the scope is narrow. The artefact is not. A one-page schedule that names the firm, the systems it can reach, and who holds which duty is the thing you can hand a reviewer. A verbal understanding that "they stay in the background" is not. The intellectual-property clauses that make the output yours are a different document. What belongs in a white-label subcontract is that document. This one is about whether the client is entitled to know the document exists.
The reason reviewers ask is older than the AI Act, and it is about visibility rather than about trademarks. NIST's supply-chain guidance puts the problem in one sentence: "Identifying cybersecurity risks throughout the supply chain is complicated by the information asymmetry that exists between acquiring enterprises and their suppliers and service providers." Acquirers "often lack visibility and understanding of how acquired technology is developed, integrated, and deployed and how the services that they acquire are delivered" (National Institute of Standards and Technology, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, SP 800-161 Rev. 1 updated, 1 November 2024, section 1.5.2). Your client is the acquirer. You are the supplier. If you cannot name the firm that wrote the system, you are not solving the asymmetry. You are the asymmetry, one tier down, and you will discover that when the questionnaire arrives rather than when you designed the engagement.
There is a measured reason the questionnaire got sharper. Verizon's 2025 Data Breach Investigations Report, the 18th edition, analysed 22,052 real-world security incidents, of which 12,195 were confirmed data breaches, occurring between 1 November 2023 and 31 October 2024. "The percentages of breaches where a third party was involved doubled, going from 15% to 30%" (Verizon, 2025 Data Breach Investigations Report). Read the caveat with the number. Third-party involvement in that series includes exploited vulnerabilities in other people's software and supply-chain compromises, not only a subcontracted engineering team. The contributor set changes from year to year, which Verizon says in the same report, so the doubling is not a clean measure of "agencies who hid a partner." It is evidence that a large incident corpus now finds a third party in 30% of confirmed breaches, up from roughly 15%. That is why a security reviewer asks the question as a default. It is not a reason to answer it falsely.
Three moments make silence the expensive choice, and they are checkable before kickoff. The first is paper you already signed. If the client's master agreement forbids subcontracting, or requires prior written consent, the disclosure is not a courtesy. It is the difference between an engagement and a breach of the agreement you used to win the work. Read it. A surprising number of agency MSAs forbid subcontracting in a clause nobody negotiated because the template was written for staff the agency employs. If the clause is there, you either get consent or you do not take the work. Describing the engineers as your employees when they are not is a misrepresentation, and we will not do it.
The second moment is the name on the system, in the sense Article 25 uses it. You are about to ship an assistant, a scoring workflow, or a customer-facing agent under your client's brand or under yours, and someone will later ask who the provider is. If you cannot point at a written allocation of who holds the technical file, the evaluation record, and the incident duties, you have the trademark and not the role. For a system that is not high-risk and not in the Union, no statute may force the issue this year. The acquisition, the enterprise security review, and the customer's own customer will force it anyway, because they are buying a named system from a named firm and they will ask who can change it.
The third moment is the questionnaire, and it is the one agencies lose by surprise. The question is rarely "did you white-label this?" It is "does any third party have access to our systems or data, and who are they?" A true answer of yes, with a name and a scope, is a normal answer. A true answer of yes that you render as no is the incident, whether or not anything is ever breached. The credential design that makes the true answer boring — named accounts, a register, production write held on your side — is a different article. What access to give a subcontractor is that design. Disclosure is the decision to be able to say the name. Access control is what the name is allowed to touch. You need both, and neither substitutes for the other. A founder sorting their own customer's spreadsheet into product controls and company controls is a different job: your first security questionnaire.
What you still do not hand over is the relationship. The client should not need the partner's name to get an answer on a Tuesday. The engineers do not join the client's Slack as a second vendor. The partner's logo does not appear on the status page. The rate you pay the partner is your margin, not a line the client audits, unless the contract you signed says otherwise. The partner's other clients are not a reference you are free to give. Who your client trusts when you subcontract is what happens when those boundaries slip and authority moves to whoever answers the hard question first. Telling the contracting party that a firm exists does not cause that slip. Letting that firm become the client's lead does. What you still keep in your own name after you have told them — the model account, the production keys, the golden dataset, a score you can re-run without the partner — is what to keep when you subcontract AI. Agencies refuse disclosure because they fear the second and end up doing the first badly.
How to tell them is short, and it belongs in the statement of work rather than in a dramatic meeting. One paragraph is enough. The legal name of the delivery firm. The categories of data and systems it will be able to reach. That intellectual property assigns to you, and through you as your contract with the client already requires. That you remain the client's counterparty for acceptance, invoices, and incidents. That the client may ask, and will be told, who had access between two dates. Send that paragraph to the person who signs and to the person who owns security review. You do not need to brief every stakeholder who will see a demo. Audience is not the same thing as existence. Existence is disclosed to the people whose job is to know. The demo stays under your name because that is what you sold.
There is a version of the conversation that is still the wrong one. Announcing the partner in the kickoff as a co-equal vendor, with their own commercial contact and their own escalation path, is not transparency. It is a second sale, and it trains the client to go around you the first time something is late. The test from the trust article still applies after you have disclosed: could you run next quarter's planning with this client and no one from the delivery team in the room? If the honest answer becomes no because you introduced them as the people who know, disclosure did not protect you. It replaced you. Disclose the entity. Do not donate the relationship.
Some engagements should not be disclosed because they should not be subcontracted. The client has forbidden it and will not consent. You cannot say what data the partner would see, because you have not looked. The work is a production system that writes to a ledger or a customer record, and nobody at your firm can accept or reject the result. In that last case the failure is not secrecy. It is that you sold a judgement you cannot perform, and naming the partner will not create the judgement. Staffing model, dedicated team or augmentation, is a prior choice. This article assumes you have already decided a subcontractor is the right shape. If you have not, do not use disclosure as a way to avoid deciding.
Nothing here is a claim about an agency engagement we can show you. Those sit under the same non-disclosure we would sign with you, and a partner willing to publish the last agency's customer in order to win you will publish yours to win the next one. What can be shown is direct work, under our own name. Gigbase is a multi-tenant workspace for agencies: projects, clients, contracts, invoicing, and an assistant that admins train, with role-based access for agencies, admins, and team members. It is not a white-label subcontract and it should not be read as one. It is evidence that the permission boundary — who may see which client — is a thing we build on purpose when the product is itself an agency's book of work. The same boundary is what your disclosure paragraph is describing, one tier up.
Price is unaffected by the paragraph, which is why people leave the paragraph out and think they have saved something. The client is paying you for an outcome under your paper. What you pay the delivery firm is an input to your margin, agreed before you sold the work, not a number that appears because you told the truth. Pricing states the commercial shapes — assessment, sprint, rescue — and not a rate card, because a number printed without a scope is the wrong number. Disclosure does not move you from one shape to another. It makes the shape you already sold survivable when someone asks who did the engineering.
On Monday, before the next kickoff, answer four questions in writing and keep the page with the contract. What is the legal name of every firm that will be able to reach this client's systems? What can each of them see, in categories a reviewer can understand? Which clause allocates the duties that follow from your name being on the system, even if no statute has arrived yet? Who at the client has already been told, by name of role? If you can answer all four without opening a chat, you are white-labelling. If the first answer is "I would have to ask," you are hoping. A white label software development partner should be able to put its own legal name in that first blank without a negotiation, and should expect you to be the one who tells your client. An AI readiness assessment is the bounded way to find out, on work you are already running, whether the blank is empty.
Find this useful? Tell Google to show you more of it.