Privacy differs from security because security can remove an intruder, while privacy harm cannot be reversed once information is exposed.
2
Organizations should collect only the data they need, obtain consent for its use, and anonymize it when possible before using it for machine learning.
3
Privacy compliance cannot be reduced to a checklist because whether data is anonymous depends on context, combinations of data, and the people involved in protecting it.
Summary
Cat Coode explains data privacy through her background in engineering, security, and privacy law. She distinguishes security, which protects systems from unauthorized access, from privacy, where disclosure can cause permanent harm. Regulations such as GDPR, CCPA, and PIPEDA put the individual before product innovation, although smaller companies often lack the money and time to comply. For machine learning teams, the starting point is data classification. They should collect only what they need, get consent, and remove identifying details where possible. Anonymization is contextual, since postal codes, small groups, or combinations of tables can reveal a person. Cat argues that privacy work belongs across product, engineering, customer-facing, and executive teams. She also warns that GDPR compliance is not a simple certification or checkbox exercise. Her example from Blackberry shows why fixing a product's privacy foundation early costs less than patching a flawed system later.
Privacy harm cannot be undone after information escapes
Cat Coode separates security from privacy with a castle analogy. Security protects assets and keeps unauthorized people out. If someone enters, the system may remove them. Privacy concerns what happens after someone learns information about an individual. Once the information is exposed, the harm has already happened, and the data cannot simply be put back. She says organizations need to prioritize privacy alongside security because a single disclosure can matter even when a security risk calculation treats the chance of intrusion as low.
Privacy regulations put the individual before rapid product innovation
Cat describes GDPR, CCPA, and PIPEDA as attempts to put individuals first. Technology companies can create an app quickly, but they may not stop to consider what the product does to its users or their data. Privacy rules ask companies to consider those effects before design and launch. She agrees that smaller and medium-sized companies often take compliance less seriously because fixing old systems costs money and requires time they do not have. In her experience, some teams have budget for only one of the many changes needed.
Data classification should come before machine learning use
Cat says the first step for an organization is to list the data it collects and classify it. Information that identifies a person, either alone or combined with other information, needs protection. Technology can remove identifying fields so that useful data remains for machine learning. After personal information is stripped out, the remaining data may be easier to use. If identifiable information stays in the system, the organization must protect it and make sure the person consented to that form of processing.
Anonymization depends on context and can fail when datasets are combined
Cat rejects the idea that data is anonymous simply because names or obvious fields have been removed. If several anonymous tables can be combined to identify someone, they were not anonymous. A postal code may seem safe in a city but identify a person in a rural area with one house. She gives another example involving a small school dataset where a non-binary student's category could reveal exactly which student the data described. Automated classification tools can help, but they cannot replace contextual judgment.
Machine learning can coexist with privacy when data is made less identifiable
Cat says machine learning and privacy regulations can coexist, depending on what an organization collects and how it uses the data. Teams should look for less identifiable substitutes, such as city instead of postal code, age range instead of full birth date, or a group such as women aged 30 to 34 instead of one person's exact details. Large datasets may make this easier, while small datasets containing sensitive information require more caution because unusual characteristics can identify someone.
Privacy responsibility belongs across the organization
Cat says assigning a data protection officer does not solve privacy by itself. The officer may need to ask development teams about privacy by design, encryption, anonymization, and test data, then rely on simple yes-or-no answers. Product managers need to avoid collecting unnecessary sensitive data. Developers need to protect transfers and storage. Customer-facing staff need to handle data access requests correctly. Executives need to provide the time and budget. She observes that smaller companies can sometimes make progress faster because fewer teams and products need to change.
Compliance is not a short checklist or an instant certification
Cat says there is no official GDPR certification, so companies claiming to provide one are misleading customers. ISO 27701 may give organizations that already follow ISO standards additional privacy guidance, but it is not a simple GDPR measurement. Cat uses a 14-page checklist because short online checklists hide important questions. A company may say it supports privacy by design or data access, but still lack answers about authentication, system load, and how the request actually works. Proper review requires reading and applying the regulation in detail.
Privacy by design prevents expensive architectural repairs
Cat compares privacy foundations with Blackberry's old calendar code. Hard-coded date logic made a daylight-saving change require updates across many old versions. The team kept patching the system until it finally had the authority and time to rebuild it. The rebuild cost more at that point, but later saved more time and money. She applies the same lesson to privacy. Collecting less data means protecting less data, and encrypted transfers reduce the chance of a privacy incident. Privacy by design gives new features a sound base instead of forcing them onto an unstable system.
