Salesforce, Inc. (CRM) Earnings Call Transcript & Summary

Hello, everyone, and welcome to our webinar today, Insights on Navigating Privacy and AI Compliance in 2025 and Beyond. Thank you all so much for joining us today. And before we begin, I'd like to just share a quick few notes about our webinar platform. So today's webinar will be available on demand after we wrap up, and you can access it through the URL you're currently on. Please note though that the slides will advance automatically throughout the presentation, and you can enlarge the slide or the media player tool. If you do require any technical assistance, just click on the help widget, and we've also provided some additional resources for you to take a deeper dive into the content and the topic that we're discussing today. And lastly, we encourage you to submit your questions at any time throughout our presentation using the join the conversation and Q&A box. We'll do our best to answer as many questions as we can at the end of the presentation. And with that, let's kick it off. So my name is Priya Kanjia. I work on the product marketing team here at Salesforce for our Trusted Services products. And prior to my life at Salesforce, I worked at a Salesforce customer where a big part of my role is managing our technology compliance procedure. So excited to be talking to you about this along with our amazing presenters. Before we jump into our content, just a quick reminder that we are going to be talking about regulation today, but this should not be interpreted as legal advice. Please do seek out independent legal advice specific to your organization. And a reminder to make all of your purchasing decisions based on currently available products. And with that, we just want to say thank you for joining us today. This topic around data security and global regulations and privacy, especially now with this uprise and focus on AI, has been top of mind for customers and especially Australian organizations, and we're excited to talk to you about it today. So you may have been at a recent Salesforce event or you may have joined a webinar on a similar topic around what we're talking about today. So today's session will cover the latest information as of today. We will do an overview of the Privacy Act and Australian regulation. Then we're going to go into a discussion around what you may want to consider for your organization around this and the topics we're discussing. So privacy and how we talk about privacy is changing in Australia. You may have been seeing headlines around data breaches. Or you might be a leader at an organization thinking about what you need to keep top of mind. Or you even might be thinking about this as a consumer what do you need to be aware of, how do you keep yourself educated? And this is something that we're learning is very top of mind for all Australians all around the country. A recent Australian privacy survey revealed that almost half of respondents suggested that they've been advised by an organization that their personal information has been breached. 3/4 of them experienced harm as a result of that. And over 90% of Australians have expected business and government to be doing more to protect their data. So as an organization, what should you be thinking about so you're not just associated with a statistic like this? And with that, very excited to have 2 experts here at Salesforce on security and compliance with us today to walk us through our session. Rachel Baker is Privacy Counsel here at Salesforce. She advises the company on privacy risks across Asia Pacific, and she sets up global compliance systems and works on data protection with our Salesforce customers. And also excited to have Leo da Silva here with us, too. Leo is a security architect here at Salesforce with extensive experience across cloud services and technologies. He's worked in a mix of large and complex environments on scalable security solutions for global companies, both as a SME and as a lead consultant. So excited to have both of our speakers here with us today. And with that, we're going to kick it off. I'll hand it over to Rachel.

Thanks, Priya, and thanks, everyone, for joining us. It's great to be with you. So as Priya mentioned, I'm going to be talking about the privacy issues that are relevant to the use of AI and also how reform of Australia's Privacy Act affects how we use AI technologies. So first, just taking a look at the sort of basic issues and considerations. So what are the privacy implications of using AI technologies? And is AI covered by the Privacy Act? Well, we know that AI is fueled by data. And to the extent that data is personal information, so that means information about an identifiable individual, you will need to comply with privacy laws. So here are 4 things to keep in mind in relation to the intersection between privacy law and AI. First is the types of data. Are you using personal data? Are you inputting personal data into an AI tool? If so, whose data is it? Where is that individual located? Because that will, in most cases, determine which country's privacy law you need to comply with. Is that sensitive data? So is it information about an individual's health or religion? If that's the case, then more stringent requirements can apply and stronger consent requirements. What was the collection method? Did you get that data directly from the individual or via a third party? And if you collected it directly, what did you say to the individual at the time of selection about what you'd be doing with the data? So did you disclose that AI processing would take place? What is the purpose of processing? So you can consider, for example, the difference between, say, a government department using AI processing for the purpose of preventing crime versus a private company using AI processing to sell more of its product. And that kind of gives you an indication of the various legal bases that you can rely on depending on the purpose of your processing. And finally, what are the effects of the processing? Are there any unintended consequences? Could an individual lose or gain a benefit as a result of this AI processing? So this might include things like if there's an automated process that could result in a fine being issued or if an automated process could lead to an individual missing out on an employment position they've applied for. The effects of the processing are important to understand the risks to individuals' rights and therefore any safeguards that you would need to build into your AI program. Okay. So let's take a look at how Salesforce set up our AI program. So we know that AI has potential to bring enormous benefits to the world, to Salesforce and to our customers. But it also carries significant risks. So the key for us has been to keep our values front and center during the development and use of AI programs. So trust has always been our #1 value, and it's critical to ensure that when we're using AI, we're doing that in a way that is safe, inclusive, reliable and promotes trust. Customer success. So we want AI to boost productivity and help our customers deliver amazing experiences to their customers. Innovation. So we want AI to be redefining work across all industries. Equality. We believe that every human being should be treated equally, and that should be preserved and promoted by the use of AI. And finally, sustainability. So we want to bring the full power of Salesforce and AI technologies to help the world on its journey to net zero and a more sustainable future. So putting those values into practice, there's 4 key guardrails that we deploy. Firstly is awareness of AI. So we want to be transparent about the use of AI and about the presence of AI-generated content. Bias and toxicity safeguards. So these are guardrails to help make sure AI systems don't produce harmful or malicious content. Explainability and accuracy. So this is about helping to make AI more reliable and accurate. And finally, hallucination reduction. So this is a set of policies and prompt instructions to help avoid the generation of false content. Okay. So turning now to the Privacy Act reform in Australia. The Privacy Act here was passed back in 1988. So it was one of the earlier privacy acts in a global context, and that's really reflected in the way that it is -- that is framed. It doesn't have a lot of the sort of hallmarks of modern privacy legislation that we're sort of seeing around the world at the moment. For example, there's no distinction between controllers and processors. So controller is the organization that makes decisions about how information is processed and why, and the processor is the organization that carries out the controllers' instructions. So that's a distinction that really has arisen more recently. It's not currently in the Australian Privacy Act. Our Privacy Act doesn't have that distinction. It also doesn't have the sort of comprehensive data subject rights that we see in much other legislation. And it has a fairly kind of flexible pro business approach. So the government is aware that this Privacy Act is, in some ways, outdated. And it has been slowly commencing the process of updating it. So that's been happening for about the past 5 years. There's been extensive discussion and consultation. And in late last year, the first stage of reforms passed through Parliament. So let's take a look at these. So these are the reforms that have actually been passed and are currently in the Privacy Act. So number one, expanded disclosure of automated decision-making. So this means that organizations have to firstly understand the decisions they are making that affects the rights and interests of individuals, and then of those decisions, work out which are either substantially or solely automated and then disclose the personal information that is used for those decisions in their privacy statements. So we have 2 years to do that. You have until December of 2026. The law was passed in December of last year. So we've got 2 years from then to sort of do that audit work and get those disclosures in your privacy statements. Change number two is reasonable steps to protect personal information. So this is in force now, and there's -- there was already an obligation in the Privacy Act to take reasonable steps to protect the security of information. And that has just been clarified to state that reasonable means both technical and organizational measures. So technical measures include things like encryption, multifactor authentication. Organizational measures would include things like staff training and data protection policies within your organization. Change number three is more targeted penalties. So this allows the regulator to take action on less serious breaches. So mid-tier and more administrative breaches can now be the subject of a penalty from the regulator. So that means things like coming back up to change number one. For example, if an organization has failed to make those adequate disclosures, that potentially could be acted on by the regulator, whereas in the past, the regulator was really only focused on more serious invasions of privacy. Number four is penalty notices. So again, this is giving the regulator more power to enforce existing obligations in the act. So instead of having to take an organization to court and get a court ruling that the Privacy Act has been breached, the regulator has the ability to assert that a breach has occurred and issue a notice. And then that then shifts the onus onto the organization that's been fined to carry the risk of litigating to have that notice overturned. So in terms of an AI context, what this means in practice is that it really just heightens the importance of having really clear visibility of the processing and the technologies that you're using, the types of data that you're using for purposes of that processing, any risks and safeguards that you've put in place. So having all of that -- all of those records up to date will put organizations in a really good position to understand whether it's fair that a penalty notice has been issued or whether it's something that would be appropriate for them to challenge. Number five is a cause of action for serious invasions of privacy. So this gives individuals the ability to directly take action against an organization. In the past, they can only complain to the regulator and ask the regulator to act on their behalf. And now individuals can directly commence proceedings. So effectively sue an organization if there has been a serious invasion of their privacy. So it's only the kind of sort of upper-level serious breaches. But this could pave the way for class action. So a group of affected individuals could come together, pull their resources, reduce their individual risk and take action against an organization if there's been a serious invasion affecting a large number of people. So again, this just really heightens the importance of that recordkeeping and having your systems up-to-date and always having clarity about what you're doing and why and really taking appropriate mitigation steps to hopefully reduce the risk of your organization being subject to a serious invasion of this nature. And finally, greater investigation powers. So the regulator has, for example, search and seizure powers, again, just really emphasizing the regulator's ability to act on breaches of the Privacy Act in its current form plus these additional changes. But more substantial changes are still planned for Australia's Privacy Act. So firstly, the controller-processor distinction. This is something that Salesforce really supports. We think it better reflects the way data is processed in the modern economy. In -- for most data processing, there are multiple processes involved in that chain of processing. And it really makes sense for the controller, so the organization is making decisions about how and why data is being processed to bear the responsibility for that and for processes to simply be following the instructions of the controller. Change number two is a wider definition of personal information. So currently, it's defined as information or an opinion about an identified or identifiable individual. And that's going to change to information that relates to an individual. So this might seem like a trivial change. But what it does is really broadens the pool of information that is covered by the Privacy Act because even if an individual isn't a subject of the information, if it can be related to them, so things like device IDs, IP addresses or generated information about an individual or predictions in relation to an individual, this will all now be covered by the Privacy Act. So it's a much broader set of information. So again, it just heightens the importance of having secure and thorough systems in place. And this also relates to change number three, which is the broader set of data subject rights. So there's currently in the Privacy Act no right to deletion. So you can request access to your information. You can ask an organization to delete it, but there's no obligation for them to comply with that deletion request. So there is a proposal, long-term proposal. It's not legislated. There's no draft legislation for this at the moment, but the long-term plan is for there to be a confirmed right to request deletion. And remember, this would apply to that broader set of information because the definition is also planned to be widened. Proposed change number four is a higher standard of consent. So currently, under the Privacy Act, consent can be either expressed or implied. So there's a long-term proposal for that to be upgraded to consent to be voluntary, informed, current, specific and unambiguous. So voluntary means that the consent can't be conditioned on receiving service, for example. It has to be a genuine consent where individuals have the choice about whether they agree to something or not. Informed means you have to be really upfront with your customers or with your data subjects about exactly what you're doing and why and any risks associated with it. Current, that means that consent won't last forever. So depending on the circumstances, it might expire after a certain period or after a certain event has passed. Specific, that means that you can't bundle consent. You may have to separate out the separate requests that you're making for consent. And unambiguous, that just means being very clear with subjects about what you're doing and why. And the final, fifth change here is fair and reasonable processing. So this would apply in addition to any consent requirements. So if you are relying on consent as the legal basis for processing, you would still need to collect consent. And if you're not relying on consent, that means that the -- depending on whether it's sensitive information or nonsensitive information, the processing would need to be reasonably expected by the individual. As well as that, there would be this requirement for the processing to be fair and reasonable in the circumstance. So what does fair and reasonable mean? Well, we don't know yet. We don't have any further detail about what this would mean in practice. So if this was to be legislated, we would expect to get further guidance from regulators. In terms of looking overseas, this is quite a novel approach. We haven't seen this in legislation -- privacy legislation around the world. Probably the closest thing to it is the concept of legitimate interest, which is available under GDPR and some other privacy legislation around the world. So legitimate interest means where the processing is necessary for a legitimate interest of the organization doing that processing. So whether fair and reasonable turns out to be less flexible -- more generous or less generous than legitimate interest, that's something that will be determined over time. In terms of AI processing, what this means is that it's really important to understand and be aware of any unintended consequences of your processing and to keep the rights and interests of individuals front and center as you're setting up your AI program. And that really brings you full circle back to being informed by your values. So if you're clear about what your values are and if you rely on those values to establish and maintain your AI program, that will put you in a really good place to comply with privacy legislation as it exists now and also to be able to comply with stricter privacy laws that we're expecting to come down the track. That's it for me. Now it's over to Leo.

Hello. Hi, Rachel. Thanks for that. I really appreciate all the learnings, hearing you speaking about the new privacy reforms and how that might actually directly impact the way our customers not only create and develop new AI solutions but also speed up the adoption process for those same solutions. Every single customer out there is looking for ways to balance out speed and security. So I hope the next few slides, I'm going to be covering some of the -- 5 simple and effective ways that you could start your journey to really kind of create this new security management posture that you need to provide assurance not only to your business stakeholders but also to your -- mainly to your customers using these new solutions that hopefully you are already underway of creating based on new AI capabilities on our Salesforce platform. Most of the things I'm going to be covering here today, they are leveraging either Salesforce native abilities or what we call Trusted Services solutions that you can use on your Salesforce rollout. And again, if you have any questions about any of those tips and solutions that I'm going to be covering today, feel free to just type in the chat, and we can drill in after we finish the session. So let's get started. So let's start from the beginning. As I normally say, you cannot protect what you don't know. A lot of our customers, they struggle with how to get started in this process. And my advice to them, based on what I hear from our customers as well as based on my experience, is try to really understand what you have in your environment. It might be really simple. But as we all know, if you're a sysadmin in the Salesforce ecosystem, we know that it can be quite challenging to understand your data footprint, especially if you're running your Salesforce organization for quite some time. You also have some help from tools that can support you in this process. So finding sensitive data, of course, I'm talking about fields that are not clearly labeled as sensitive information. You might have an object with a field called credit card or PII data. I'm talking about things that might be written in free text fields or fields that have been -- or custom objects containing fields that have not been correctly labeled and classified. So how do you provide assurance that all your sensitive information has been identified, categorized, and of course, treated, handled correctly? So you have to start from a really kind of thorough process in identifying this data in your Salesforce organization, and on top of that, use that as a main starting point of creating policies and creating structures in your Salesforce org that allows you to protect this data throughout the entire life cycle of the use. How do you do that? How do you actually improve the way you classify and label this data in your environment without disrupting any activities or any permissions that might be assigned to these objective fields? So we know based on our research that 34% of organizations say they have a data readiness strategy. But if you conversely look at it, we have a huge number of organizations that don't know exactly how to treat data sensitivity and data access from a strategic point of view. So to take this safer approach in understanding and identifying this data, we do have a solution that we call data classification. Data classification is a feature that we just released as part of our new Security Center extension package that allows you to use a really simple wizard to walk you through different steps to list, identify, label and classify this information. That allows you to really kind of get a better understanding of what you have in your environment. With data classification, you take the burden away from this process because, as I said before, it can be really difficult to do that at scale, and you need to have some sort of tool to support you in this process. We are quite confident that data classification is a simple and effective way that you can use to effectively run this process in your organization today, and again, without disrupting any of your existing processes. So if you haven't had a go at understanding and classifying the data today, I really kind of ask you to have a go at it and try yourself in your organization to see if this is something that you would like to explore. So now that you identify the first sort of set of data in your environment, what do you do next? So access control is normally top of mind for a whole bunch of our customers, right? So you now have the footprint of your data. You understand where the sensitive information is stored. Now you want to control access to who does what in your environment, who can see what, who can actually explore data, who can modify data, and of course, permissions throughout the Salesforce organization. So understanding all the different permissions as well as the overall security configuration of the environment is key to a proper security management strategy. So if you want to really kind of understand and restrict access to this data, to avoid or at least mitigate some of the risks associated with this access in your environment, you have to have a better grip in the way you understand these controls, right? So having a proper classification framework in place, and of course, establishing those controls will allow you to apply security at scale, and of course, allows you to provide evidence that you are implementing the controls that you have to either your internal auditors or any external products that require you to kind of provide them with that proof of implementation and effectiveness of your controls. So if you are looking for a way to really kind of understand and audit your environment, not just your main organization but any other connected organization that you might have being in production or sandbox environment, Security Center is definitely your best friend to achieve this outcome. At Security Center, we have a lot of out-of-the-box builders that can be used with little to no knowledge of Security Center. It's pretty kind of straightforward. There's a wizard that guides you around setting up alerts or setting up different metrics that you want to follow. But on top of that, if you are really kind of looking to making Security Center tailored to your own needs, we provide you with the ability to create custom metrics, which is something that a lot of our customers were really happy to have access to. So because now you can, of course, have this specific metric created that gets populated by data that is relevant to the organization. It might not be relevant to any other organization out there. So you can create something that is your own, and you can keep a close eye on it throughout the entire process, which is quite powerful. Another cool item that you have access once you have Security Center installed in your environment is something that we call what -- who see what explorer. So this is a really nice addition to Security Center that we just released. That allows you to understand what -- which users and which roles and permissions are granted to specific users across the entire Salesforce organization. So think about it as your reporting capability that tells you exactly what user can see what object or field over source. That is quite powerful, especially for those organizations that have multiple users, sometimes hundreds of them. And they're really kind of struggling to understand the different permissions assigned to them. So this is something that if it's a problem that you're facing today, you might want to have a look at this new feature of Security Center that's been just released last month. So what do you do then next? How do you actually, again, support your business in this process of creating new AI solutions, of course, without breaking rules or reducing any potential risk associated with that? So we see a lot of our customers creating sandbox environments and giving access to that environment to the developers and sometimes external consultants so they can come in and create these new solutions and new applications, which is quite standard approach, right? So you don't want them to be accessing a production environment, but at the same time, you want to give them production-like kind of data so they can use that to create environment -- create the solutions, create the applications and test them before you roll them out to your users in the field. So we also have this understanding that sandbox environment quite often don't have the same TPU standards that we normally apply to your production environment. It's fair to say that sandboxes are normally seen as a low-level environment that may not have a lot of scrutiny applied to it. But if you think about how those sandboxes are created, especially full copy sandboxes where production data is then copied across to this environment, you need to have at least the full understanding of how we protect the data that is copied to this environment. And better than that, you want to avoid sensitive information to be used in accessing the sandbox environment. The best way for you to achieve this outcome is, of course, protect this data before it gets accessed in the environment. And with this outcome, you have the option to use data masking capabilities. With data masking, you can actually apply a different strategies being anonymization, pseudo anonymization, even deletion, if you want to, of this data before it hits your sandbox environment or at least before it gets accessed by any developer or external consultant in your sandbox organization. So you can de-identify this information, but at the same time, allowing them to use production-like data that will not slow them down in producing -- in developing these applications to your business. So you really want to kind of apply this level of control to stop data to get leaked before anything like that happens. You want to ensure that data is protected as soon as it leaves your production environment. You do have other ways to achieve that outcome, but based on our experience, using something like Data Mask is quite effective, especially if you look at the ways we can now bypass any automation that you might have. Not long ago, there was a bit of a blocker in some cases where you had to disable those -- the automation before running the data masking jobs. But now this is no longer a problem. You can do this automatically. And all your data gets protected based on your policies. And you can then -- after the job is done, you can provide access to the environment in a more secure way. This is something that a lot of our customers, they start off thinking about data masking purely from a security perspective, trying to remove this information from the sandbox environment. But then if you look at the level of compliance and the cost of fines that come from potential data breaches and going into the hands of unauthorized users, you really got to have to take a step back and think about the overall consequences of you not handling this data properly. And that's why I always tell my customers to if they are really kind of invested in creating those sandbox environments and handing them over to developers and external users, you really want to think about protect information at all times. So Data Mask is definitely something that you should have in your toolbox and use it to process data throughout the entire SDLC process, right? So we cover identification. We cover auditing. We cover Data Mask protection in your sandbox environment. Now how do you protect this over time? How do you ensure that all controls that you're actually creating and implementing are being used correctly and not deviated from your standard? You have to have some sort of proactive monitoring in place that allows you to create alerts and even trigger automation to prevent something further to happen in your environment based on your policy standards or external regulation, right? So the way you can achieve that is by leveraging Event Monitoring. Event Monitoring is our solution to really kind of give you this single pane of glass approach to understand all the security events, both using objects in our platform or real-time streaming to your external SIEM, if you do have one. You can leverage even more to kind of give you all the information that you need to be on top of your security management at all times. So monitoring and logging things that are commonly used in other systems, especially for security operation centers, they really want to make sure that you have this cohort from a Salesforce perspective because they do have a lot of information -- extensive data stored in the platform. So all the security stakeholders, they really need to be at least able to observe what goes on in the environment. So a lot of our customers approach us from this sort of point of view, trying to get the security operations center. All the security stakeholders are aware of everything that goes into the Salesforce organization. And then Event Monitoring is definitely the best approach to kind of creating this observability kind of solution on top of Salesforce platform. You can not only get information, but you can learn from the insights. You can establish trends. You can establish learnings from it and create policies that allows you to protect information before anything happens. A good example of that is transaction security policies, right? So you do have specific objects and fields that now you have classified that contain sensitive information. So you want to have some sort of way to protect -- report exporting containing this object or containing this information. So you can create TSPs that not only block access to that specific report export action but also get informed if someone tries to export more than 100 rows of data. All this kind of proactive assurance that you can implement in an environment that comes from the use of transaction security policies that are part of our Event Monitoring product suite, have a look. If you're looking for ways to really kind of keep on top of everything that goes into the environment as well as provide that sort of evidence to your compliance team about all the different controls that you have and any threats that might be being observed in the environment, Event Monitoring is definitely the best kind of approach to add this control to your environment for sure. Last but not least, we need to talk about privacy. Rachel covered a lot of the changes in our privacy reforms in Australia. There's a lot more to come. We're expecting this to be an evolving situation, at least in the near future. So how can you be on top of this? How can you actually be sure that your data is protected and your customers' information is protected at all times? So our customers, they need to understand that moving forward, they will have to implement a robust privacy and compliance program if they really want to kind of retain their customers and respect their customer preferences, right? So with something like what we're seeing in the market, having the ability to create right to be forgotten and data subject access requests to their customers is seen as a positive when it comes down to security maturity model that the service providers actually have. And customers really appreciate the fact that the service providers are looking after the data at all times. So having that privacy management approach that allows customers to [indiscernible] exactly what kind of data, the consent and the ability to remove them from your system should they want to is seen as a competitive advantage by a lot of customers in Australia today. So even though it might not be an obligation under any Privacy Act today, you really want to kind of think about it from a customer standpoint, what can you do to ensure that your customers' information is protected at all times and you're actually applying the right level of control at any given point in time throughout the SDLC process in your Salesforce organization. So privacy center includes data management policies and tools, right? So it allows you to kind of create those different mechanisms to export data from a specific user or move that specific information to a different [indiscernible] sitting outside your Salesforce organization. So you have a lot of options that can be applied. But also, you can perform anonymization of data or pseudo anonymization of data in production, which is different from what we covered in the data masking topic, which is targeted to sandbox environments. Privacy Center can help you achieve similar outcomes in production. So if you're looking for ways to protect information that you might not even need to store for a long period of time and you want to retain some of that but some of the fields or information might be protected or deleted altogether, you want to probably have a look at Privacy Center in the way you can create this privacy management process to control customer data in your environment. Also, all the different policies allows you to really kind of comply with privacy laws and especially around consent management, right? So you can use the Privacy Center to connect it to data cloud, for instance, to become your kind of -- the heart of consent management even for downstream and upstream systems. If you have other platforms kind of handling consent for specific parts of the organization, you can still kind of send that into Salesforce and to get managed by Privacy Center, which is quite powerful. You want to have a look at this if that's something that you are interested in. So in a nutshell, we are seeing privacy as an area where a lot of our customers are really kind of making a lot of investment in and trying to get a better grip and better how they can serve the Australia customer. And if that's your situation today, if this is something that you want to explore further, please have a look at Privacy Center because as we understand, this is something that is a quite powerful solution that can help you achieve this outcome. So Priya, I think it's over to you now, right?

Yes. Thank you, Leo. Great overview on the topic by Leo and Rachel. Thank you both. I think just a lot of great insights, great introduction to the topic as well as really interesting to hear about what you're seeing in the industry and what you're hearing from customers. So with that, as we start to wrap up, if you will be in the Sydney area on May 20, we are going to continue this conversation with Leo. We're going to have a customer discussion on this topic at our upcoming Agentforce Financial Services Summit coming up at the ICC. I encourage everyone to reach out to your account executive to learn more about this event and sign up. Open and free for all, and would love to have you there to continue the conversation. And I saw a couple of questions in the chat around just deeper guidance, more advice on best practices. So please take a look at both of our reports on the screen now and scan these QR codes. The one in the middle is a deep dive of the steps in the session that we went through today around considerations for strengthening privacy and compliance around these global regulations in this environment and take a closer look as well as at the other resource, 6 Security Steps to Prepare for Agentforce to think about this through an AI lens. And with that, we do have a couple of minutes left. I'm going to invite Leo and Rachel back up for us to go into a Q&A. And again, great to see all the questions coming through on the chat. I am going to try my best to summarize, and we will try our best to answer as many of them as we can. So question number one. A lot of questions around just AI and privacy. So can I ask you both, how do you see AI being addressed as part of the privacy regulation? Do you see consent being required for AI processing? Any thoughts around how you see just this with the AI lens on top of it?

Thanks, Priya. I'm happy to answer this one, Leo, and I'm sure you'll have some views you want to share as well. So look, I think the key thing to remember at this point under the Australian Privacy Act and most other privacy legislation around the world, AI is, in most cases, not regarded as a specific part of privacy. So it really comes back to those fundamental questions in the slide I shared at the start of my presentation is, are you processing personal information. So if you are using AI technology to process personal information, you need to comply with the Privacy Act. And the same principles will apply to that processing, whether it's AI processing or whether it's more traditional forms of processing. In terms of whether you would need specific consent for AI processing, under the Privacy Act as it stands now, it's more based on kind of reasonable expectation and the purpose of collection. So if you collect information from an individual and say, I want your information to process it for -- using my AI technology for this purpose, and they agree to that and give you your information, then you could -- that's -- you have the legal basis. You don't need a separate consent. If you collect personal information from an individual for a particular purpose and you'd say you've already got their information and what you want to do is additional processing for a different purpose, whether that's using AI or not, the question is going to be, is it sensitive information? So is it information about their health or religion or political beliefs? If so, you are going to need separate consent. If it's not sensitive information, then the question is, is this additional purpose of processing reasonably related to the initial purpose? So these are really kind of broad, principle-based concepts, and it's going to really be very dependent on the circumstances. But it's just trying to protect individuals from processing that really had nothing to do with their reason that they thought they were providing their information for. In terms of would an individual reasonably expect this AI processing to occur, again, it's going to depend on the circumstances. It's going to depend on what they were thinking at the time they gave you their information. So it's going to depend on a lot about what you said to individuals at the time, at the point of collection, what was in your privacy statement, how did you ask for their information. That is going to be really relevant in terms of understanding whether a specific or a separate consent is required for the AI processing.

Yes. Great. Thanks, Rachel. I think this question is related to what you just asked. With the change of the definition of personal information, will information such as water meter number or vehicle identification number be considered as personal information? So maybe -- I know you talked about in the presentation, but maybe can we just go on a deeper level of just -- can you just explain what personal definition is defined as in this context?

Sure. So personal information means information about an individual who is either identified or identifiable. So identifiable means it's possible for someone to find out who that person is based on the information that you've provided. There is a proposal to change this definition. So instead of being about an individual, it's in relation to an individual. And this question really picks up on exactly these types of sort of peripheral information around a person connected to a person that the person is not the subject matter of. Like a person is -- a car is not about a person, for example. But could that vehicle identification number be treated as personal information? So again, it's going to depend on the circumstances if that vehicle identification number or VIN relates to an individual. So for example, if you were to go into the VIN database and you could see that a particular number was owned by an individual at a particular address or was registered to a particular address, for example, and say 1 or 2 or 3 people live at that address, then the chances are that, yes, that would be regarded as personal information and be subject to the Privacy Act. On the other hand, if that vehicle is registered to a corporation with 1,000 employees and could be driven or used by any one of those employees, then it's looking less likely that it relates to an identifiable individual because the pool of individuals that it relates to is so large that it's going to be less likely to identify any one individual.

Thanks, Rachel. I see what you mean about the context and all those like very important in how this is interpreted. Some -- a question here around updating sensitive fields based on classification or other details. So Leo, maybe can I ask you just any best practices around managing sensitive data fields? I know you talked about data masking, but just your thoughts or advice kind of around this topic?

Yes, sure. I think we need to start from having a proper naming standard in place. In all the cases, we see customers adopting -- especially for custom objects, they have like fields with names that are not really understandable. And those fields actually contain sensitive information that no one knows about it. So investing some time in creating a proper naming convention that can be used in the organization helps a lot. If a field that you know will eventually contain sensitive data, make sure that's being classified, labeled, the sensitivity is being correctly assigned to that and do the basic security hygiene, right? So that's, of course, the #1 approach you can take. But in all cases, customers, they have environments with a lot of objects and fields already created, and they struggle to kind of understand how they can -- moving forward, how can they apply this kind of concept to the Salesforce rollout. So you can try to do this manually. You can look at the most used objects in the organization and have a look at different classification strategies and different labeling strategies. But I guess you want to have a more sort of comprehensive approach and having a tool that can help you achieve this outcome is your best option. So I was quite impressed when I started to use the data classification feature of Security Center, that helps customers achieve that outcome. So my tip, a little bit biased, but my tip will be have a look at it. If it's something that you're struggling with today, have a look at how this can help you moving forward.

Thanks, Leo. I think it's a great question and point, I think, for a lot of organizations. Probably if you're on this webinar and new to this topic, it's just how to get started, right? So helpful, I think, to understand the context of what are the considerations, what are kind of my processes to even start with this conversation. We still have more questions coming in. So in the context of still to come, there was a reference to being current and aiming for a higher standard of consent. Are there any thoughts on how current might be defined and applied? And could this be varied based on industry? Rachel, any...

Yes. Thanks, Priya. So that is a good question. And unfortunately, it is going to depend on the circumstances. I think you've got to have to look at the purpose of processing. For example, if, say, I provide personal information for the purposes of a particular transaction, once that transaction is complete and all the services that I ask for have been provided, then you would -- that kind of suggests that additional consent might be required for additional separate unrelated processing down the track. On the other hand, if there is an ongoing relationship between an individual and an organization and there is, say, interaction from the individual with the organization, that suggests that the relationship is ongoing. And you would be less likely to need to recollect consent if there's an ongoing relationship between the individual and the organization. So it's very dependent on the circumstances.

Thanks, Rachel. I think we're coming close to the end of our webinar. Maybe one more question. I think a question to you both. For someone who might be new to this topic -- and again, I think we went through a great conversation today. But again, it might be overwhelming for someone who's new to this or for an organization that's just getting started. Any advice on where they can kind of begin their journey, what to kind of be considering or where to get started in terms of just like this privacy regulation, like everything going on with AI? Any thoughts on that?

I can have a quick one. Rachel, if you want to. Look, my advice -- and I'm not talking specifically about Salesforce. It's more like your security management of data across different environments. Don't wait until any privacy reform or act becomes an obligation for you to do something about it. Be at the forefront of what needs to be done and apply the basic security controls that your customers would expect from you. In a lot of cases, when those different reforms come into law -- become law and come into action, there's a lot of struggle that goes into kind of cleaning up the environment and doing something that kind of brings your level up to the new standard, and you don't want to be caught up in that situation. So if you want to really get started, I would advise you to look at what you have today, understand your current data strategy, understand how the security controls can be applied beyond what your Salesforce mandate might be today. You have to have a more holistic approach because if you're talking about AI, there's a lot of downstream and upstream processing that may happen in this situation. So you want to kind of look at from different angles and look at what maybe other customers in other regions are now starting to apply as well. If you look at how GDPR came into play in Europe and now it's kind of a global standard for a lot of things, we believe that it might happen with a lot of the AI regulations that are coming up as well. So yes, be mindful of what's happening in the world and try to do your part in the organization.

That's good advice.

Sorry. Thanks, Priya. I'll just quickly respond on that one, too. I was just going to say that from a privacy perspective, I think the key is to really have your data well organized. So you know exactly where personal information is and where you can find it in the event that you need to comply with data subject requests in the future and also to have clarity on what data you have, the purpose of processing that is valid for that data, any consents that you've collected from the individual and what individuals have consented to because that will put you in a really good place to be able to comply with the stricter obligations as they come into force.

Great. Thank you both. I think I'm hearing just like -- step one is really just like get yourself educated and have a pulse in your organization and your data, it all starts there, and that's only going to continue to have more weight, I think as AI... [Technical Difficulty]

I think we just lost Priya there, but I think she was just in the process of wrapping up the presentation. So thank you, everyone, for coming. Thank you, Leo, for your -- Priya's back. Okay. Back to you, Priya.

Thanks. Sorry, minor tech issue, but I'm back. I think we have time for one more question. So this one is a scenario -- a specific scenario question. So if your organization does -- say your organization is not directly using AI to process information upon the time you receive consent from the customers. But later on, you implement a technology solution, a software that then begins to use AI processing. Does the organization now need to go back to the customer to seek additional consent?

Thanks, Priya. Yes. Look, just briefly, it's going to depend on the purpose of that AI processing. So if it's an entirely unrelated purpose and would not be reasonably expected by the individual, then yes, you would need consent. But if you're just updating the technology you're using to fulfill the same purpose, then it's less likely that you'll need a separate content.

Thanks, Rachel. And with that, I think we're coming up right against time. Thank you, everyone, so much for joining our session today. Great questions, great engagement, and a big thank you to our 2 speakers. Again, you will get the recording of the session, and please follow up with us for any questions. And take a closer look at the resources we have shared as well, which you'll get in the recording. And with that, thank you all for joining.