Privado AI

48% of websites at least had one consent mode misconfiguration across the US and Europe.

Meta’s $18B teen settlement exposes a problem privacy teams tend to underestimate Age is becoming a production dependency. Once a platform gives under-18 users different protections, age has to influence real system behavior across the product. Recommendations. Notifications. Ads. Account controls. Usage limits. Safety systems. That sounds simple until you look at the architecture. Age may be self-declared, inferred, verified, supplied by a parent, or derived from other signals. Each method carries a different confidence level. Then that signal has to reach every service that depends on it. A useful way to audit this is Source → confidence → propagation → enforcement → logging For each age-sensitive feature, privacy teams should know → where the age signal originates → how confidence is represented → which services consume it → what happens when signals conflict → whether enforcement can be verified later The hard failures usually happen downstream. One service has the correct age state, another uses stale data, a third never received the signal. The policy can still look perfect while the product behaves inconsistently. For companies building age-dependent experiences, age assurance is starting to look a lot like identity infrastructure. That has implications far beyond social media. #PrivacyEngineering #DataPrivacy #AIGovernance #Privacy #Law #Meta

Google just made one of the biggest AI privacy questions impossible to ignore. A single “delete my data” action can mean very different things once that data has entered an AI pipeline. Google’s new Search Services History controls cover activity across products such as Search, Maps, Lens and Translate. Google also explains that some data selected for AI training may be disconnected from a user’s account and retained under a separate lifecycle That distinction matters because legal teams often define deletion around the source record. AI systems create more layers. The same piece of data can exist in an account record, a product log, a copied dataset, a training corpus, an embedding or another derived artifact. Each layer can have its own retention period and deletion mechanism. So privacy teams need a more precise definition of deletion. When a user deletes data, engineering should be able to show which systems receive that instruction, which copies are removed, which data is de-identified or detached, and which derived artifacts remain. This is where AI governance becomes much more technical... a privacy notice may contain one sentence about deletion. Engineering may need six different controls to make that sentence accurate. That is the standard I think AI privacy programs should move toward, define deletion by data state, map every downstream copy, and make the limits visible before making the promise. Policies describe intent. Systems determine whether the promise holds. #AIPrivacy #DataPrivacy #Privacy #Law #DataGovernance

TikTok’s $400M privacy settlement exposes a problem most age-gating systems don’t solve. TikTok and ByteDance recently agreed to a $400 million settlement with the U.S. Department of Justice over alleged violations of children’s privacy laws. The headline is about COPPA... the deeper issue is about how age is handled inside complex systems Most companies treat age as a registration field just ask for a date of birth, classify the user, and move on. But large platforms keep learning about users long after signup. Behavioral patterns, account history, parental reports, trust-and-safety signals, and age-estimation models can all suggest that the age originally provided may be wrong. That is where the real privacy challenge begins. If a user is later identified as a child, that change cannot live in one account database. It should affect advertising, analytics, recommendations, data retention, profiling, and third-party processing. The tough segment is propagation. One system may classify the user as underage while another continues processing their data under the original age setting. That is the gap privacy teams need to focus on. Age assurance is a data-governance problem. A strong children’s privacy program should be able to show how a change in age status travels across the technology stack, what processing stops, what historical data is affected, and whether downstream systems actually enforce the same decision. That is where compliance becomes real in the systems that act on what the company knows. #DataPrivacy #PrivacyEngineering #COPPA #DataGovernance #PrivacyCompliance

$2.25 million!!! That’s what RentGrow agreed to pay after the FTC alleged its tenant-screening system made some people look more risky than they actually were. The part privacy and AI governance teams should pay attention to is that the source data itself could be accurate. The failure happened when RentGrow assembled and displayed it. According to the FTC, duplicate criminal and eviction records sometimes appeared multiple times in a report, creating the impression that an applicant had more convictions or eviction cases than they actually had. That is a data pipeline problem with a legal consequence. Tenant screening systems pull from multiple sources, match identities using names and historical addresses, combine records, deduplicate them, and turn the result into something a landlord can act on. A failure in any one of those steps can change the outcome for a real person. The FTC also alleged that RentGrow used historical addresses and middle names from LexisNexis Accurint for matching, but did not always disclose that source when consumers asked where their information came from. For legal teams, that raises two questions that deserve far more attention- 1/ Can we trace every decision back to the source data and transformations behind it? 2/ Are we testing joins, matching logic, duplicate handling and data lineage, or only reviewing the final model and policy? A company can have accurate source data and still produce an inaccurate decision system and that is where privacy governance often loses visibility. #AIGovernance #Data #Privacy #Legal #Tech

OpenAI’s new teen safety mode has a privacy problem hiding in plain sight. To protect minors, ChatGPT may first need to analyze enough signals about you to decide whether you are one. OpenAI says ChatGPT for Teens will activate when a user identifies as 13–17 or when the system estimates that the user is under 18 using self-reported age, account signals, behavioral signals and verification. That sounds like a safety feature but technically, it is also an identity and inference system. The important privacy issue is what happens underneath parental controls. A system now has to collect signals, infer an age range, attach that classification to a user and make sure the decision follows that user across every system where different protections should apply. That includes model behavior, logging, personalization, analytics, safety systems and potentially other downstream infrastructure. This is where legal intent often breaks. A policy can say that minors must receive stronger protections but if one service knows the user is likely under 18 while another service operates on a different identifier and never receives that signal, the protection exists on paper but not across the full data flow. There is another issue privacy teams should not overlook. The age estimate itself becomes sensitive governance data. Teams need to know which signals created it, how long those signals are retained, whether the underlying behavioral data is kept, where the resulting classification travels and what happens when the system gets it wrong. This is going to matter far beyond OpenAI. AI systems will increasingly infer attributes about people in order to decide which legal, safety or product rules should apply to them. That means privacy governance can no longer stop at what data a company collects. It also has to govern what the system concludes about a person, how that conclusion was created and whether the resulting control follows their data everywhere. Policies describe who should be protected. Systems determine whether that protection actually happens. #Privacy #AIGovernance #DataPrivacy #AgeAssurance #PrivacyByDesign #ResponsibleAI #ChatGPT

Most vendor privacy reviews become outdated the moment the next deployment goes live that sounds extreme until you remember that the questionnaire reviewed a company, while the risk lives in constantly changing code. A privacy team approves a vendor on Monday, the answers look clean, limited data collection, approved subprocessors, 30-day retention, deletion on request, etc. On Thursday, an engineer upgrades an SDK. Nothing in the contract or questionnaire change. Nobody reopens the assessment. But the SDK starts sending one additional identifier to a new endpoint. From Legal’s perspective, the vendor is still “approved.” From the system’s perspective, the data flow has changed. This is the operating gap I think privacy teams underestimate. Vendor assessments are built to capture declared behavior. Modern software creates runtime behavior. Those two things drift. Sometimes because of a new SDK. Sometimes because of an API change, a logging configuration, a new subprocessor, a retry queue, or a developer shipping something nobody thought was privacy-relevant. This is why observability matters for privacy. Not because lawyers need to become engineers, but because they need a way to verify whether the system still matches the promises they approved. A useful privacy program should be able to compare three things: - What was promised. - What was approved. - What actually happened. If those three cannot be reconciled, the assessment is unsuccessful. We would never audit financial controls by asking, “Did the control work?” and accepting “Yes” as sufficient proof. Yet privacy still does this every day. Policies describe intent. Systems reveal reality. #privacy #data #legal #engineer #law

California just fined a data broker $52,400 for failing to register. It was CalPrivacy’s second enforcement action against an unregistered broker in less than a week. On the surface, this looks like an administrative miss... it isn’t To know whether a company needs to register as a data broker, legal first needs an accurate view of what the systems are actually doing. Where is personal data coming from? Is it collected directly from the individual or acquired elsewhere? Which data is being sold or shared? What inferences are being created? Which entity is responsible for those flows? These are not questions a privacy policy can answer on its own. They require visibility into the underlying data architecture and that is where many privacy programs still have a gap. A new vendor is added, a product starts using third-party data, an audience model creates new categories of inferred data, a subsidiary launches a new service and nothing may change in the legal documentation that day. But the company’s regulatory position may have changed immediately. The Cybba enforcement is also notable because the remedy goes beyond paying a fine. The company must connect to California’s Delete Request and Opt-Out Platform, process deletion requests through it, and publish privacy-rights metrics. That is a useful signal of where enforcement is heading. Regulators are looking at whether the underlying systems can actually execute the obligation. and CalPrivacy is widening the scope from unregistered data brokers to sensitive health data and larger multinational companies. For legal and privacy teams, a periodic assessment is no longer enough. You need a way to detect when changes in products, vendors, data sources, and business models create a new privacy obligation. The actual risk is discovering too late that your systems changed the answer. That is the part privacy programs should be pressure-testing now. #privacy #law #legal #fine #data

Samsung just banned smart TV apps that could turn your television into residential proxy infrastructure for companies like Bright Data and one of the apps researchers flagged was a Pac-Man game that should concern privacy teams for a reason that goes beyond smart TVs Samsung banned residential-proxy SDKs after researchers found apps capable of sharing a user’s internet connection with third parties. The interesting part is how this can bypass normal privacy review. Legal teams usually review a defined artifact, a specific app version, a list of SDKs, declared data uses, permissions and vendor documentation but production software is increasingly mutable. An SDK can receive new server-side instructions. Remote configuration can enable functionality after launch. Code can be loaded dynamically. New endpoints can appear without anyone submitting a new app version for legal review. That creates a serious governance gap A privacy review may be accurate on launch day and outdated two weeks later, even though nobody in legal received a change request For higher-risk apps and SDKs, privacy teams need a baseline of expected production behavior which third parties receive traffic, which data leaves the device, what each SDK is allowed to do, and which changes should trigger another review If an SDK starts contacting a new domain, transmitting a new identifier, or activating functionality outside the approved use case, that should be treated as a material system change Privacy approval cannot be a one-time checkpoint when software behavior can change after release The policy may stay the same. The app may stay on the same version. The system underneath can still change. #data #privacy #law #lawyer #legal