Outsourcing software development from Washington

Washington outsourcing at a glance

This table is a procurement control, not a conclusion that a particular Washington law applies. The buyer must establish scope from the real workflow and current sources before it asks an international provider to implement it.

Build a health-data and inference stop gate

Do not limit discovery to fields labeled “medical.” Washington’s My Health My Data Act contains its own definitions and provisions for consumer health data. A wellness quiz, search history, purchase, precise location, symptom note, appointment signal, model output, prediction, or inferred association may require a different review from an ordinary product event. A developer cannot settle that question by renaming a database column.

Before real consumer data enters a repository, prompt, ticket, log, analytics tool, test fixture, or support channel, create a health-data and inference inventory:

1. Input: What does the person type, upload, record, purchase, search, or allow the product to observe?
2. Derivation: What rule, model, segment, embedding, score, or human judgment is created from it?
3. Claimed purpose: What user-facing function requires each input and output?
4. Entity and consumer: Which organization determines the use, where does the relevant person interact, and which legal definitions may be implicated?
5. Movement: Which buyer system, provider, model host, analytics service, annotator, support tool, and subprocessor can receive it?
6. Choice and notice: What current privacy policy, consent, authorization, or other process applies before collection, sharing, or sale?
7. Rights and lifecycle: How can the buyer locate, export, correct where required, delete, revoke, propagate a request, and prove completion?
8. Security and incident: Which privileges, encryption, logs, alerts, escalation, and evidence apply?

Assign a product owner, privacy or legal reviewer, security owner, and engineering owner. Record the approved decision and version. If the analysis is incomplete, use synthetic or purpose-built non-person data where it can answer the engineering question, or stop the feature. “We are not a hospital” and “the model only inferred it” are not scope analyses.

Review exemptions and interactions with other regimes explicitly. The current statute contains exemptions and does not convert every health-related workflow into the same set of obligations. A qualified reviewer should determine what applies to the entity, data, and use rather than assuming that another regulated-data program either resolves or expands the Washington question.

Turn processor terms into executable instructions

The current Washington statute includes a processor section describing a binding contract and processing consistent with instructions. For a buyer, the practical challenge is making those instructions observable in engineering and operations. A clause saying “process only as directed” is weak if the supplier can add an AI assistant, send logs to a new region, or reuse data for evaluation without a control or approval trail.

Create a processor instruction packet tied to the system design:

• approved data categories and representative examples;
• permitted purpose and operations for each category;
• prohibited inference, combination, sale, sharing, training, marketing, and unrelated reuse;
• named environments, accounts, regions, people, roles, and access durations;
• approved models, APIs, analytics, observability, annotation, and support services;
• subprocessor request, evidence, approval, change notice, and emergency path;
• security, logging, export, request assistance, deletion, backup, and verification steps;
• incident triggers, preliminary notice, evidence preservation, containment authority, updates, and cooperation;
• contract end, access revocation, asset transfer, deletion certificate, and surviving records.

Link each instruction to enforcement evidence: policy-as-code, tenant setting, network rule, secret boundary, pull-request review, deployment record, data catalog, log, or test. Name who can approve an exception and when it expires. The buyer should be able to identify a provider deviation before a consumer complaint or incident makes it visible.

Exercise the packet during the pilot. Submit a test request, revoke one permission, change one approved service, and ask the provider to show what happens in active storage, logs, backups, and downstream services. If the answer depends on one salesperson or undocumented manual knowledge, the operating control is not ready.

Stop geofence features before implementation

RCW 19.373 includes a geofence restriction around entities providing in-person health-care services for specified purposes. A Washington buyer considering proximity messaging, attribution, audience building, visit measurement, safety alerts, or location-driven personalization should stop the feature before a provider selects an SDK or begins collecting coordinates.

Document the proposed boundary, location source, precision, refresh rate, purpose, user population, trigger, output, retention, recipients, and alternatives. Separate a genuine functional need from marketing convenience. Review whether an on-device, coarse, user-initiated, or non-location design can meet the product outcome. Do not let a supplier treat an advertising-platform default as the buyer’s legal or ethical decision.

This stop gate belongs in discovery, architecture review, acceptance criteria, and change control. A later model or analytics update can create a location inference even when the original feature did not store raw GPS coordinates.

Design Pacific-time delivery around authority

Use the buyer’s actual Washington city and an IANA identifier—commonly America/Los_Angeles—with the provider cities and project dates. Daylight transitions may differ across jurisdictions. Recalculate the schedule for the engagement rather than recording a single UTC offset.

Separate four windows:

• Product decision: the buyer can approve scope, behavior, and acceptance.
• Sensitive-data approval: privacy, security, health-domain, and legal reviewers can authorize a change in data or purpose.
• Technical resolution: buyer and supplier leads can resolve an interface, evaluation, or release blocker.
• Incident command: a named person can stop access, preserve evidence, and coordinate response at any hour the system operates.

Teams in Latin America may offer broad same-day overlap with Washington, depending on the cities and dates. Teams in Europe can combine a Washington morning decision with later-day implementation. Asia-Pacific teams can create an effective follow-the-sun handoff for bounded work. None of those patterns is automatically better. The right pattern depends on how often the work needs live buyer authority, how complete the handoff is, and whether the proposed people can sustain the schedule.

Require a written handoff containing accepted outcome, current artifact, evidence, open risk, blocked decision, responsible person, and next authorized action. Do not make an offshore engineer infer sensitive-data authority from a chat reaction sent after the buyer’s day ended.

Choose the engagement before the destination

A specialist freelancer can fit a narrow implementation or review when the Washington buyer owns product, architecture, integration, and quality. Staff augmentation can fit when the buyer already has strong delivery leadership. A managed provider can fit a bounded multi-role outcome when it supplies a named lead and accepts explicit operating responsibilities. Direct international employment may fit a durable role, but it is a different employment and compliance decision from buying a service.

Write a responsibility matrix for requirements, data classification, consent or authorization decisions, architecture, development, evaluation, security, deployment, production access, consumer requests, incidents, acceptance, documentation, and exit. A project fee does not create managed accountability if the buyer still coordinates every difficult boundary.

Only then compare provider countries. Verify the contracting entity, each proposed contributor’s city and relationship, subcontractors, normal hours, data and tool locations, rights chain, replacement process, sanctions and export considerations where applicable, and continuity. Country averages cannot prove that the named team fits the work.

Govern AI services and health-related outputs

Maintain an approved AI service register for hosted models, coding assistants, vector stores, annotation, evaluation, observability, and agent tools. Record account owner, model and version, hosting entity, region, inputs, outputs, prompts, embeddings, logs, retention, training use, subprocessors, access, monitoring, deletion, incident route, and replacement.

For a feature that produces health-related classifications or recommendations, define intended use, prohibited use, evaluation population, representative cases, failure modes, uncertainty, thresholds, human review, user communication, rollback, and monitoring. Do not allow a supplier to invent a diagnosis, eligibility decision, or risk threshold because a model returns a convenient number. Qualified product, health-domain, legal, privacy, and statistical reviewers should determine which evidence is required.

Control supplier-side AI as well. Production data, consumer support records, screenshots, logs, source code, and architecture should not enter an unapproved assistant. Enforce the rule where feasible through accounts, network controls, data loss prevention, secret management, repository policy, and review rather than relying only on training slides.

Evaluate the named team and rights chain

Separate the provider company, proposed people, and delivery system. Verify the legal and invoicing entity, relevant insurance or financial evidence, references, subcontractors, dispute route, and continuity. Interview the people who will perform and lead the work. Confirm allocation, location, normal schedule, sensitive-data access, and substitution rules.

Ask the team to walk through a comparable artifact from request to operation: decision record, code or configuration, review, tests or evaluations, secure-development evidence, release, monitoring, incident response, and handover. NIST’s Secure Software Development Framework can organize supplier questions, but use practices proportionate to the actual product and access.

Separate buyer background materials, provider background materials, new deliverables, open-source components, data rights, prompts, evaluation sets, models or derived artifacts, documentation, and operational records. Verify the rights chain from every employee and subcontractor. WIPO’s national office directory helps locate official destination-country resources; it does not prove ownership or transfer for the proposed contributors.

Keep repositories, domains, cloud, model accounts, package registries, analytics, and recovery methods under buyer governance. Use individual least-privilege identities, protected secrets, reproducible releases, current runbooks, backups, and a tested offboarding sequence.

Calculate complete cost and downside

Normalize proposals for the same accepted outcome and responsibility allocation. Include named roles, seniority, allocation, delivery leadership, privacy and legal review, health-domain review, evaluation, security, model and cloud usage, tools, currency, fees, travel, shifted hours, support, rework, rate changes, replacement, and transition. Show uncertain items as ranges with a validation action.

Track buyer hours, decision delay, accepted outcomes, defects, control evidence, request completion, schedule sustainability, and exit readiness. A lower hourly rate can be more expensive when the buyer must reconstruct the data flow, chase access records, or rebuild supplier-owned infrastructure.

Model downside. Ask what happens if a processor uses data outside instructions, a model vendor changes retention, a consumer request reaches multiple copies, a location feature is misclassified, a lead leaves, or the supplier must be replaced in a week. Budget the controls that make those events containable.

Run a Washington instruction-boundary pilot

Choose a paid milestone that tests the hardest operating boundary without unnecessarily introducing real health data. Include one product decision, a synthetic or approved dataset, implementation, peer review, tests or evaluations, security evidence, documentation, acceptance, and handover.

Require the proposed people to execute the instruction packet. Add one controlled change: remove a contributor, replace a model, deny an unapproved service, process a test deletion request, or transfer a deployment into the buyer account. Observe whether the provider can identify every affected system and produce evidence without improvisation.

End with a written continue, revise, or stop decision. Do not scale because a demonstration looks persuasive when scope is unresolved, the real team was absent, data movement is unknown, critical accounts remain supplier-owned, or deletion and exit cannot be demonstrated.

Washington buyer red flags

• The provider says health privacy is irrelevant because the buyer is not a hospital.
• Product discovery records only raw fields and ignores model inferences, segments, prompts, embeddings, and logs.
• “Process only as instructed” has no technical controls, service register, or deviation alert.
• A location SDK is added before the geofence purpose and boundary are reviewed.
• Pacific-time coverage is promised without named people, cities, dates, and a sustainable schedule.
• A supplier can add a model host, analytics tool, or annotator without buyer approval.
• Real consumer data appears in demos, tickets, laptops, or AI assistants because synthetic data was inconvenient.
• Consumer-request support stops at the buyer database and ignores provider systems, logs, backups, and subprocessors.
• Source, cloud, model, or recovery accounts remain supplier-owned.
• Exit language exists, but revocation, export, deletion, and rebuild are untested.

Frequently asked questions

Does every Washington wellness or AI product fall under the My Health My Data Act?

This guide makes no blanket conclusion. Inventory the actual entity, consumer, inputs, inferences, purpose, collection, sharing, sale, location, and exemptions; compare the workflow with the current statute and Attorney General guidance; and obtain qualified review before supplier access.

Can a Washington company use an international processor for consumer health data?

Do not infer permission or prohibition from geography alone. Determine applicable law, role, contract, instructions, data locations, subprocessors, security, consumer-request assistance, incident response, and destination-country requirements for the exact arrangement with qualified advisers.

Is a model output consumer health data if the input was ordinary product behavior?

The label is not enough. Record the input, derivation, output, intended use, person, entity, and downstream handling, then obtain a current scope analysis. A supplier should not decide classification merely because it produced the inference.

What is the best outsourcing country for a Washington company?

There is no universal best country. Define the outcome, Pacific-time decisions, skills, data and sector boundaries, engagement model, contract, complete cost, and continuity. Then compare named teams in eligible countries using the same evidence model.

What should a Washington software pilot test?

Test the proposed people, instruction packet, approved tools, secure-development evidence, buyer-controlled assets, one rights or access change, written handoff, and the ability to stop without losing work or data control.

Is Outsourcing.ai located in Washington?

No local presence is claimed. This is an online buyer guide, not a Washington office, local-business listing, or representation of local employees or clients.