In 1958, Leonard Read wrote a fascinating piece on productive interdependence through a thought-provoking autobiography of the pencil.1 Its family history ran through cedar forests in Oregon and Northern California, graphite mines in Ceylon,2 clay from Mississippi, and wax from Mexico. No single individual, in Read’s telling, possessed all the knowledge required to make the pencil from scratch.
The analogue3 illustrates how people could accomplish together something no individual could accomplish alone. Read’s argument centered on the coordinating power of markets. For our purposes, the pencil offers a familiar starting point for understanding a modern digital supply chain: a seemingly ordinary product whose simplicity depends on an extraordinary amount of work being done upstream.
A customer speaking with an AI voice agent encounters a similar arrangement (though unquestionably with more computing involved4). The telephone connection, model, application, and customer records all depend on different providers. The customer may interact with a single service, but a request made during that conversation may need to pass through several systems before anything actually happens.
Modern business depends on this division of labor. A company can sell an excellent product without needing to possess every skill and resource required to bring it to market, and a specialist can serve many customers without understanding every use they will make of its contributed expertise. The resulting interdependence is productive, and relies on individuals who establish that the assembled product performs as promised, including where one supplier’s contribution meets another’s.
I.Out Sourcing
Forty-two years before the publication of Read’s pencil prose, New York’s highest court was considering a much less cooperative piece of wood.
Donald MacPherson had been thrown from his Buick when a wheel collapsed.5 Buick had purchased the wheel from the Imperial Wheel Company, a reputable supplier (that happened to be located only about a hundred yards away). It had checked that the wheel ran true and hadn’t been damaged in shipment, and even took the car on a test drive.
Because MacPherson had purchased his vehicle through a dealer, he had no direct contract with Buick. Nevertheless, in 1916, the court held that Buick owed him a duty of care.6 Benjamin Cardozo explained that buying from a reputable manufacturer did not discharge Buick’s inspection duty. They were, he determined, “responsible for the finished product.”7
The ruling concerned a defect discoverable by reasonable inspection. Cardozo expressly left the liability of component manufacturers open. Its relevance here is the distinction between selecting a reputable supplier and establishing that the supplied component is suitable for the finished product.
Technology procurement encounters that nuance routinely. A provider’s evidence may establish how its service performs under specified conditions, and yet your deployment will inevitably introduce a unique configuration, other dependent services, and/or customers who expect it to behave in unanticipated ways. Understanding what the test covers is part of deciding how much confidence to place in the result.
The sensible response to specialization is to establish what you can rely on, what needs verification, and what should happen when change is introduced into the system. Trying to know everything would diminish the core value proposition of buying from somebody else instead of developing it yourself.
A well-run supply relationship allows the necessary knowledge to pass through. Specifications tell the supplier what matters and testing provides evidence about performance. Traceability connects a finished product to its contributing materials, services, and processes. Change controls give the customer a chance to examine a substitution before discovering it through complaints. In a digital supply chain, that substitution could be a background model update or a new third-party subprocessor introduced mid-flight8. That assurance is central to what the customer is buying.
II.Through the Usual Channels
The central difficulty is that the commercial relationship has a different incentive structure than the finished product or service. Your organization might sign a contract with an application provider that uses an external model, runs on another company’s infrastructure, and sends information through additional services for their own monitoring and support (or all three). The purchasing relationship runs through procurement, but the information being processed has a number of potential diversions.
Third-party risk management is a well-established practice for evaluating outside relationships. Fourth-party risk pushes oversight to the providers behind your provider. The terminology was developed to describe commercial distance (not necessarily how consequential a particular dependency might be).9 A service you had no part in reviewing can still have very direct legal and market consequences.
That distance also affects what providers are obligated to provide. For example, privity (the direct contractual relationship MacPherson lacked with Buick) matters when you need a supplier to produce records or investigate an incident, or even change its behavior. Contractual flow-down provisions may be included to require relevant obligations to pass into subcontracts, but their usefulness depends on which obligations carry and how they are enforced.
Cloud computing’s shared responsibility model addresses another part of the arrangement by allocating security considerations and obligations between provider and customer. There can be huge disparity in that allocation based on the specific service purchased and the configuration used.10 Even when the division of labor is clear around infrastructure security, it can fall apart when determining if an AI agent’s action was appropriate in a particular business process.
Then there are the standard terms in the other sense: the supplier’s paper. You’re no doubt familiar with the key terms: warranties that describe promises; audit rights provide a way to examine performance; and liability caps and indemnities address core elements of financial exposure. Even where all four are covered, there can still be open questions. For example, an availability commitment doesn’t necessarily establish that a chatbot conversation will be completed correctly. An annual supplier report might provide important information without supplying the records needed to investigate a critical failure. A promise to notify you of a new subprocessor needs enough information, time, and an available response for the notice to be useful.
Whether the “standard terms” terms support the product you are assembling requires a closer reading.
III.Batteries Not Included
Twilio publishes a tutorial for connecting its telephone services to OpenAI’s Realtime API for outbound calls. The tutorial has a prominent reminder for developers to address TCPA compliance.11 Twilio’s platform provides ease of integration that not many years ago required considerably more independent development. But it also leaves the purchaser with consequential decisions about how to use it.
In Lowrey v. Twilio, William Lowrey alleged that he received unwanted calls and texts advertising probate services. When he called back and asked for a representative so he could request that they stop, he was met with an automated message that sounded a lot like an OpenAI quota error.12
Twilio, for their part, has argued that they did not control the messages’ content, timing, or recipients. OpenAI argued that its voice technology engaged only after a call was answered. On October 1, 2026, a federal judge found the allegations sufficient to treat the providers’ combined activity as making or initiating calls under the Telephone Consumer Protection Act. He described them as “telemarketers—albeit the 21st century version of them.”13
The distinction from Buick here is that with Lowrey the court is examining the providers’ alleged participation in the regulated activity. Being one component of a larger service does not, by itself, establish what legal responsibilities accompany that participation.
And to make matters more interesting, the legal conditions surrounding the service may change. The FCC is considering a request to relax prior-consent requirements for certain noncommercial political calls to wireless numbers, including calls using AI-generated voices.14
For a provider serving many different customers, with different requirements supporting their own customers, that raises a practical question: how would any resulting distinction between permitted uses reach the upstream product? Someone would need to establish which campaigns qualify, which conditions apply, and how those conditions affect the configuration. And the same infrastructure can support very different activities. Permission to make a particular call would still leave open questions about its content, the handling of an objection, and the information collected during the conversation. Those questions reach beyond the telephone connection to the organizations developing the solution behind it.
IV.Following the Instructions
Data protection law has been addressing this kind of distributed responsibility for years. A business can ask another organization to store its records, operate its software, or analyze its customer information while retaining duties concerning what happens to that data. And the supplier may have additional obligations of their own.
For example, under the GDPR15, the controller determines the purposes and means of processing personal data. The roles of processor and sub-processor in this case depend on the actual activities being undertaken. Any vendor at any step of the data chain that goes beyond instructions and determines its own purposes and means can inadvertently become a controller for that processing.
And if you’re evaluating AI services, this gets even more interesting. Handling information to answer a customer’s question, and then retaining it to train the supplier’s product are distinct activities that each require examination.
There is also a small linguistic complication. Businesses routinely describe an outside processor as a “third-party vendor.” The GDPR’s defined term “third party” excludes the processor.16 This can create a difference of terms between procurement and privacy counsel that gives the appearance of agreement even where both organizations are actually considering different categories altogether.
Article 28 gives the data processing agreement (DPA) a substantive job. The binding arrangement must address matters including documented instructions, confidentiality, security, assistance with individual rights, deletion or return, and evidence of compliance and audits.17 Those provisions all have operational counterparts. For example, a promise to assist with a request may have limited practical value if neither party can, in fact, identify the relevant records.
The requirements expressly extend down the chain. Subprocessors require prior specific or general written authorization. General authorization entails notice of intended additions or replacements and an opportunity to object. The same data protection obligations are imposed downstream, even as the initial processor remains fully liable to the controller for the subprocessor’s performance of those obligations.18
In its 2024 opinion, the European Data Protection Board explained that controllers should have the identities of all processors and subprocessors readily available. The extent of verification varies with risk, but the need to identify the chain remains for lower-risk processing. This can be a useful distinction for an executive evaluating the cost of oversight. Knowing who performs the work and obtaining sufficient evidence about it does not necessarily require duplicating every supplier’s entire diligence process (reenacting the inefficiencies we discussed with the physical supply chain earlier).
Responsibility can also attach to a particular operation within a larger arrangement. In Fashion ID, a retailer embedded Facebook’s Like button on its website. Applying the GDPR’s predecessor directive, the EU’s highest court explained in 2019 that the retailer could be a joint controller for collecting and transmitting visitor data to Facebook without being a controller for Facebook’s subsequent processing.19 Purchasing or embedding a feature can involve decisions with legal consequences, even when it is another organization that operates the underlying technology.
California uses its own categories: service provider, contractor, and third party. Under the CCPA, qualifying disclosures require agreements addressing specified purposes, privacy protections, oversight, and remediation. Service-provider status depends on satisfying statutory requirements, including restrictions on the use of information.20
Global sourcing adds another layer. An agreement governing the processing relationship does not (merely by existing) establish a lawful international transfer. Where GDPR transfer rules apply, the arrangement needs an applicable transfer basis and the safeguards that basis requires.21 You need to know where the work goes before deciding whether the documents cover it.
These classifications answer different legal questions from those in Lowrey. A supplier’s privacy role does not settle whether it participated in initiating a telephone call. For a technology executive, the practical consequence is that the vendor assessment needs to follow the activities being purchased.
V.According to Spec
Consider a hypothetical voice agent whose customer says, “Stop calling me.”
The model understands the instruction and acknowledges it. The application saves the transcript and (via integration) writes the request into a notes field. The campaign system checks a separate suppression field, which remains unchanged even as another call is already being queued. Even though every component completed the task it was configured to perform, the customer may still receive another unwanted call.
This experience is familiar to anyone who has had to deal with a replacement part that looks right, but fails to fit. The specification for a component only helps if it captures what the assembly requires. A capable model can recognize the customer’s intent while the application lacks the connection or authority needed to carry it out.
The scope of the delegated function matters legally as well. In the July 2024 decision in Mobley v. Workday, the court allowed claims to proceed on an agency theory involving delegated hiring functions.22 It distinguished ordinary spreadsheet and email tools from software alleged to participate in deciding which candidates advanced. The ruling did not establish that discrimination had occurred.
For the purchasing organization, the useful analysis involves evaluating what the service has been entrusted to do. Producing a transcript, recommending an action, and executing a consequential decision introduce different dependencies. An evaluation designed around the first will tell you precious little about the third.
This is where legal and technical work need to meet. Counsel establishes the relevant obligation, including its scope and timing. Technical and operational teams determine how the system carries it out across the participating services. The resulting evaluation needs to test the consequential action, including what happens when a dependency becomes unavailable or returns an unexpected result.
For the hypothetical calling system, that means tracing the request through the application, customer record, campaign rules, and queued activity. For a data request, it may mean identifying which providers hold copies and how an instruction reaches them. In either case, the evidence needs to establish more than whether the model understood the sentence.
VI.Behind the Curtain
The executive challenge is that the necessary information is usually distributed as thoroughly as the work.
Procurement knows which supplier signed the agreement. Security knows the controls reviewed during onboarding. Engineering knows how the services connect. Legal knows which representations the business has made. And though each team possesses accurate information, a change understood by one may never reach another.
A model replacement could affect previously tested behavior. A new subprocessor could alter the data path. A configuration change could make an existing assurance less relevant without making the assurance itself incorrect. The organization needs a way to connect those changes to the people responsible for assessing their consequences.
It also needs enough evidence to reconstruct a failure. One provider may retain the conversation, another the attempted action, and a third the resulting change to a customer record. Those records have to connect if they are to explain what happened.23 Contractual rights matter here because they determine what cooperation is available. So do technical access and the authority to intervene. Suspending a campaign, reverting a configuration, or invoking a fallback requires someone who can actually perform the action.
This is also where the distinction between financial protection and operational control becomes concrete. An indemnity may allocate a covered loss, subject to its terms and the supplier’s ability to pay. It does not update a suppression field or retrieve a record from a subprocessor. Both kinds of protection can have value; the product needs the ones that allow the business to respond while the activity is still underway.
The appropriate depth of oversight will vary with the function and its consequences. What should remain visible is the connection between the obligation, the supplier performing the relevant work, and the evidence that the assembled service fulfills it.
VII.Finished Goods
Read’s pencil explains why specialization is worth preserving. Technology companies benefit enormously from capabilities developed elsewhere, and their customers benefit from the products those combinations make possible. Requiring every company to reproduce its suppliers would sacrifice the core of that value.
The work of understanding the finished product remains. In a digital supply chain, that includes the connections between services, the uses of information, the functions delegated to providers, and the changes introduced after purchase. A supplier’s assurances contribute to that understanding when their scope is clear and their evidence reaches the people who need it.
At Privlex, we bring legal oversight and technical evaluation together around that assignment. We identify the obligations attached to the deployed activity, examine how the system carries them through its suppliers and integrations, and connect findings to changes that can be verified.
Your customer may not need to understand every organization involved in delivering the service, but your business needs to know enough to stand behind what it has assembled.
Joe Ewing
Co-Founder & CTO
Privlex
Twenty years building, modernizing, and scaling complex platforms across commercial, regulated, and defense environments — from generative AI to FedRAMP / IL4 / IL5 cloud delivery. Joe previously served as Chief Technology Officer at Clarion AI Partners.
His experience spans large-scale enterprise implementations, AI-enabled and data-integrated systems, and modernization for mission-critical workflows. Earlier in his career, Joe led platform and cloud modernization for U.S. defense, intelligence, and civilian agencies, delivering secure, performant systems.
At Privlex, we help organizations unlock real value and simultaneously close the gap between the governance they have on paper and the oversight they really need.