Donald Gainsborough sits at the intersection of policy, technology, and governance, translating big bets like AWS’s $50B investment into real-world outcomes for public missions while holding a firm line on privacy, consent, and transparency. In this conversation with Ethan Blaine, he connects the dots between AI supercomputing for government workloads and day-to-day choices like cookie governance, consent gating, and the practical boundaries of “strictly necessary.” We explore how milestones, compliance, and resiliency complement user trust; how opt-outs are enforced without degrading core performance; and how to communicate trade-offs honestly when personalization is limited. The throughline is clear: scale matters, but stewardship matters more.
AWS plans to invest $50B in AI and supercomputing for government customers; what core capabilities does that buy on day one, and how will you phase deployments over time? Please walk me through milestones, target workloads, and any throughput or latency metrics you’re using to track progress.
Day one, that level of investment translates into secure, high-density compute for training and inference, dedicated regions with strict tenancy controls, and a full lifecycle stack—data ingestion, feature stores, MLOps, and guardrails for responsible use. We sequence deployments in waves: first, standing up capacity and connectivity aligned to government network boundaries; second, hardening for accreditation; third, scaling specialized accelerators to priority workloads. We track progress through baskets of metrics—throughput per accelerator, end-to-end latency from data landing to inference, and time-to-approve models through governance—not just raw speed. The milestones feel tangible: capacity online, controls inherited, workloads piloted, and then expanded once agencies see not only faster results, but predictable, compliant operations.
Which government missions are first in line for the $50B build-out, and how did you prioritize them? Share an example workload, the current performance baseline, and the step-by-step path to your targeted improvement, including cost-per-inference or training-time reductions.
We prioritize missions where time-to-insight and equity matter—public health, benefits adjudication, security operations, and critical infrastructure monitoring. Take a benefits eligibility workload: the baseline is often batch processing with long queues and limited explainability. We start by modernizing data intake and establishing a clear model governance lane, then we containerize the inference service and route it through accelerators in a compliant region. From there, we tune serving pipelines and cache features to trim cost-per-inference while tightening latency variance; the real win is not a single metric, but consistent performance that respects auditability and due process.
How are you aligning the AI/supercomputing roadmap with FedRAMP, IL levels, and classified environments? Describe the control inheritance, segregation steps, and metrics you’ll use to validate compliance at each stage, plus a real-world scenario where this approach de-risked rollout.
We build compliance into the blueprint: inherit controls from the underlying cloud stack, bind services to the appropriate IL boundary, and enforce segregation through dedicated VPCs, access brokering, and scoped roles. Stage gates are explicit—attestation of inherited and implemented controls, penetration testing, and continuous monitoring. We validate with evidence: access logs, encryption posture, configuration drift reports, and findings remediation cycles. In one rollout, we used control inheritance to satisfy most baseline requirements, then isolated the training environment to prevent data intermixing; that let the agency move forward confidently without re-architecting their entire pipeline when accreditation reviewers scrutinized data flows.
What’s your plan for resiliency and continuity for government AI workloads—regions, availability zones, and failover? Walk me through an incident playbook, recovery time and recovery point objectives, and a story where redundancy design changed based on test results.
We assume failure and design for graceful degradation: multi-AZ by default, multi-region where mission warrants it, and clear failover pathways for training and inference. The playbook starts with detection and blast-radius containment, switches traffic via health-based routing, and prioritizes restoring minimal viable inference before broader retraining. We set RTO and RPO targets in agency SLAs and rehearse them through game days. In one test, we learned our model registry replication lag complicated rollback; we reworked the promotion process to ensure version pinning survived a regional failover, so the service could fall back to a known-good model without manual intervention.
How do you manage data locality and sovereignty for sensitive agencies while still giving them access to cutting-edge accelerators? Detail placement decisions, encryption key management, and the measurable trade-offs you accept on latency and utilization.
We keep data where policy says it must live, then bring compute to the data with placement controls and dedicated capacity pools. Encryption is non-negotiable: keys live in managed HSM-backed services with agency-controlled key policies, and we separate keys for data-at-rest, in-transit, and model artifacts. The trade-off is straightforward—some latency and utilization headroom is sacrificed to respect locality, and we document that delta so leaders know what they’re buying in protection. Practically, we bias for locality-aware schedulers, pre-stage model weights, and accept that the shortest path isn’t always the permitted path.
First-party vs third-party cookies: how do you separate telemetry for site performance from marketing analytics in practice? Give a concrete example of data flow, consent gating, and the reporting granularity you rely on to prove the separation.
We split pipelines at collection. First-party, strictly necessary and performance cookies record core site signals—page load, error rates, and consent state—tagged to this browser on this device for this website. Third-party marketing events are hard-gated behind consent; until the toggle is on, those tags never fire. In reporting, we maintain separate datasets and dashboards with distinct identifiers and document lineage so auditors can see the wall between operational telemetry and marketing analytics.
Your policy says some “strictly necessary” cookies can’t be opted out; how do you define that boundary operationally? Walk me through your criteria, a governance review example, and the metrics used to detect overreach or scope creep.
Operationally, “strictly necessary” means the site breaks or can’t honor choices without it—think the cookie banner and remembering privacy selections, or ensuring core performance monitoring. We use a governance rubric: purpose, minimal data, retention, access, and a test that asks, “Would the user reasonably expect this?” In one review, a convenience feature slipped into the necessary bucket; we reclassified it as functional and made it subject to consent. We watch metrics like cookie proliferation, access patterns, and user complaints to catch scope creep early.
You reference allaboutcookies.org for user guidance; how do you measure whether that external resource actually helps users? Share funnel metrics, support ticket trends, and any A/B tests you’ve run to improve comprehension or opt-out rates.
We treat that link as part of the consent experience. We measure click-through from the banner, time on the resource, and whether users return to complete a choice. Support tickets about cookies tend to decline when comprehension improves, and we A/B test banner language to reduce confusion and increase confident opt-outs where users want them. The signal we want is fewer “How do I stop this?” tickets and more decisive actions, either accepting or opting out.
The policy mentions “sale” of personal data under the CCPA and a toggle to opt out; how do you technically enforce that choice across ad tech partners? Describe the tagging, consent strings, and periodic audits, with an example where enforcement caught a drift.
The opt-out toggle creates a consent state that propagates as a standardized consent string to our tag manager. Partners only load if the consent string permits; otherwise, their tags are suppressed at runtime. We run periodic audits—both automated scans and partner data processing reviews—to ensure no tag circumvents the gate. In one case, an updated partner script tried to set a new tracking cookie; our audit flagged the drift, we blocked the script, and required a patched version before re-enabling.
You note you don’t track users across different devices, browsers, and GEMG properties; how do you honor that while still measuring site performance? Explain your attribution model, data retention windows, and a time you chose lower precision to protect privacy.
We scope analytics to a single browser, single device, and single property, as the policy states. Attribution uses session and page-level signals, not cross-property IDs, and we keep retention windows tight to support operational insights without building profiles. When a product team requested broader attribution, we chose lower precision—aggregate reporting—so we could answer business questions without violating our own boundary. The experience is quieter but truer to user expectations.
Functional and performance cookies are framed as essential; how do you prove they aren’t being repurposed for targeting? Detail tagging conventions, access controls, and any third-party assessments, plus a case where a cookie was reclassified after review.
We label cookies with purpose codes at creation, and our pipelines enforce purpose-based routing to segregated stores. Access is role-based, and marketing teams cannot query operational datasets by design. We invite third-party assessments to validate that operational cookies don’t feed targeting systems. Once, a cookie initially used to tune page rendering leaked into a personalization experiment; we pulled it back, issued a post-mortem, and split the data paths permanently.
Social media and targeting cookies are opt-out; how do you communicate the trade-offs when users disable them? Share messaging tests, click-through deltas, and a step-by-step rundown of the fallback experience and its impact on revenue.
We explain plainly: opting out means you’ll still see ads, just not tailored, and some social features may not render. We tested banner language that emphasized control and clarity, which improved informed opt-outs without spiking abandonment. The fallback swaps in contextual ads and disables social embeds unless clicked, preserving core content. Revenue takes a measured dip, but we offset it with better page performance and user trust that keeps people coming back.
You say users will still see some ads even if they opt out; what changes behind the scenes in ad selection and frequency? Walk me through the decision tree, brand safety layers, and the metrics you track to ensure relevance without personal data.
Behind the scenes, the decision tree defaults to contextual matching—page topic, placement, and general suitability—rather than personal history. Brand safety runs regardless, filtering categories based on page and partner rules. Frequency is managed at the page-session level instead of a cross-site profile to respect the no-tracking stance. We watch viewability, contextual relevance scores, and complaint rates to make sure we don’t sacrifice quality when personalization is off.
How do you synchronize cookie preferences across subdomains and over time without cross-device tracking? Explain your storage strategy, expiration policies, and a concrete incident where preference drift occurred and how you fixed it.
Within a property, we store consent in a first-party cookie that can be read across subdomains, so the same browser enjoys consistent choices. We honor reasonable expiration to avoid “consent fatigue,” and we prompt again when policies change in meaningful ways. We once found drift when a new subdomain launched without the shared consent logic; users saw mismatched banners. We rolled out a common consent module and added pre-launch checks so subdomains inherit the same behavior.
For government sites using your infrastructure, how do cookie and consent practices adapt to stricter public-sector rules? Provide a before-and-after example, the controls you implemented, and the measurable impact on analytics fidelity and user trust.
Public-sector sites usually start with broad analytics and social embeds; after review, we trim to strictly necessary and performance cookies that support accessibility, uptime, and consent remembrance. We implement explicit opt-in for anything beyond that, disable third-party tags by default, and document data flows for transparency. The analytics picture becomes leaner but clearer—fewer vanity metrics, more signal about performance and content utility. Trust indicators improve: fewer complaints, smoother audits, and better alignment with the mission to inform without surveilling.
Do you have any advice for our readers?
Treat scale and stewardship as a single design problem. For AI, invest in capacity and controls in equal measure; for privacy, make your policy as operational as your architecture. Write down your boundaries—like honoring choices only on this browser, this device, and this website—and enforce them in code, not just prose. Most of all, test your assumptions in daylight; the habits you build in the open will serve you when the stakes are highest.
