Latest / Range Podcast / Stop being scared of your IT team
Transcript
- Giac Soliman: Welcome to a new episode of The Range Podcast. Today I am here with a good friend of mine and IT strategy expert that is going to walk us through some of the most common pain points that we have in the field, right? Tobias at core used to be in strategy consulting and now got his own consulting firm focusing on shaping infrastructure, strategic project, as well as selective startup guidance and matching investors. Wow, Tobias Lipsky: Okay. Giac Soliman: that's a lot. In the end, bringing the right people together is the focus. Tobias, welcome to the podcast. Tobias Lipsky: Hi, Jack. It's a pleasure to be on your podcast. Lovely to be here and sharing a bit of my insights that I can spell. Giac Soliman: you spend a lot of your days between, talking to founders, investors and and deep tech. What is the weirdest idea or coolest idea you've heard from that room this month? Tobias Lipsky: the the most brain buggling thing is it's hard to catch up with AI and all the developments coming. So basically it feels like every other day, every other week, a new solution comes around the corner that has a different new angle. Giac Soliman: Are some of these concerns new? the concerns about data privacy, data residency, where does your data go once you feed it in an AI? And of course we need to separate enterprise licenses from personal licenses, but there's more, Tobias Lipsky: Okay. Giac Soliman: right? Are all of these concerns relatively new? Or are they is AI bringing them to surface, but are concerns that being there from an IT standpoint, which you bring Is are they new or are they same old, same old? Tobias Lipsky: So to make it like grabbable, if we all go back to when GDPR was introduced and came up the first time, there was a big fuzz around it. All the firms basically launched internal project teams dissecting what they have and how to get into it. That's the same how you have it now with AI. You dissect what you have, you look at everything again. But with GDPR, it was when it came up, it seemed new to everybody, but it was just Basically, especially in the DAC area, consolidating many laws that already were in place. And the same thing is happening now with AI. You're touching a lot of topics and a lot of tech stack strategies, how things are set up, and how you have your contracts in place. In the end, these questions have always remained. The question: how does your data get moved? What gets done with your data? Who worst case can access your data? Which IT admin has access to your HR data? This is not a question that comes up new now that you're using AI. The only new is you might have another party in it. So the question is, okay, I'm using a solution, in this case AI. Does the AI company have access to my data? But then you can mitigate all of this by saying I have my own sovereign solution or I have the enterprise and not the private solution version. So it's basically the same questions that always came up. from in previous discussions when you implement a new tool. Giac Soliman: Mm-hmm. So the problems are new. Perhaps the solutions will be. Who knows? But if we let's let's try to reframe that. Let let's assume I'm a nine year old, right? I am a comp or Total Worlds leader. I'm staring in front of a AI chatbot. Could be Claude, could be Chat GPT. Let's just assume I don't have an enterprise license. So I've everyone has access to tools now. There's a free version of it. I'm toying with the idea of doing some analysis of just pasting some in some employee data in the chat bot and asking it some questions, maybe to analyze the data set. What happens when I do that? as a as a comperson, once I press submit, what what what happens in the background? Tobias Lipsky: Well, it already happens when you upload and not just when you press submit. So that's one thing to know. Giac Soliman: Ha ha. Tobias Lipsky: The other is you you're basically getting towards the I'm bringing my private AI tool that I already have or use in my private field into the business field. And this is one of the biggest IT risks that all the firms at the moment are facing, because firms are slow in implementing and adapting AI, but their employees are using it already on a daily basis. So the minute you basically put anything into this prompt field, if it's text, you're fine. Once you already upload a file, it's being already uploaded, meaning the AI is already analyzing it. And if you take Entropic, for example, and you don't have the enterprise version, or you just use the pro privately, you're already consenting that all your data in the background can be saved, used, and well, you're already basically broke your company rules by using Giac Soliman: Right. One thing I I still don't understand fully to be used. I I have heard of people say, yeah, I knew about that, that's why I don't use my personal license. But I do have an enterprise license in my company and yet they're telling me not to upload any personal identifiable and identifiable data in it because Add sentence like we we as non tech people we just don't know why. So if I had to go to my IT department and prepare for a meeting to get those answers, right? We do have an enterprise license. Let's use Claude as an example. But IT is telling me no wait, don't don't don't upload any employee data yet. What kind of questions should I ask them? So they can help me understand why the veto, why the caution, etc. Tobias Lipsky: So basically, when you first approach IT, the first thing they'll ask you is what is your use case? What are you trying to accomplish? What do you want to get at? What do you want to get out of it? They're not going to directly jump with you into the discussion of how your data moves. They want to understand what you want to be doing and accomplishing. So they can basically already start breaking it down on an IT legislative perspective to understand how to navigate the waters. Then Moving that further, of course, you're going to touch data sensitivity discussions. And this is where it gets interesting because once you mention that you upload the most sensitive data and you want to be using that for your output, IT understands they need the hardest guardrails possible. And especially if it is identifiable HR data, usually you have an additional IT layer that anonymizes these things, or basically the system as it Processes your data will only process a unique number but not identifiable to a person. And then in the end, you as HR or COM will basically have a table to break it back down to the actual people. So the question is always where does the identifying layer happen? If this layer and identifying happens within the tool itself, outside of the sphere of the company, you got a bit of an issue. If it happens within your sphere, well You're already doing this today if you're using AI or not. how much anybody earns, the tables, you compare all of this on a daily basis. So the matching, if it happens, in your sphere and solely in your sphere, and your neighboring department can't see that, you're fine. But basically, IT will directly go with you into the discussion of, and this is also your own interest. How do you ensure that your neighboring department can't prompt the AI and then get an output company internal on something that you just uploaded yesterday? So you don't want to know, okay, when is the next comp cycle coming? How many percentages will it increase in salaries, et cetera? You don't want your neighboring departments knowing this, asking a simple question, hey chap internally, when is the next comp cycle happening? How much will my salary most likely go up? You want to have an answer then coming as in this is out of your sphere, you're not allowed to access this. But this is not a discussion on the level of AI. This is basically a discussion on company internal guardrails, data access, which you already have in place today. So the best IT is usually just transfer the existing guardrails that you have into your new system. So Giac Soliman: Right. Tobias Lipsky: taking Microsoft as an example, most people use Microsoft Environment. So you have there your sets of data, they're limited to your department, you can't access something you don't have access to. If AI basically uses exactly these same rules, you're already on a good way. Giac Soliman: Gotcha. We we touched on something that you named as identification layer, right? In in plain English, how how would you how would you define that? Tobias Lipsky: The identification layer basically is where the name of an employee or GDPR, basically of a person gets connected to its data set. So as long as the data set doesn't translate back fully to a specific person, it's non identifiable data. So for example, you have this anyways in the UHR discussions already today. You usually run it as an employee number and not by first and last name. Well, nobody knows whose employee number, like who's who's behind this one. Unless, of course, it's an employee number which is a bunch of zeros and a one. You can assume it's probably the founder. But even in that case, there's means of splitting that. If you just use employee numbers of ten digits, usually your systems will have three stars and just show the n digits. Giac Soliman: Mm-hmm. Tobias Lipsky: So this is making it anonymous and then you can work with this data because nobody knows who is behind this. And basically Giac Soliman: Right. Tobias Lipsky: AI runs it the same way. Then I AI will basically work on the employee number and not based on the person's name. Giac Soliman: Got it. And we also touched on a few other concepts. You've mentioned data residency and data sovereignty. And I think you alluded to an analogy in the past of building a house. can you take us through that a little bit more in detail? for someone that is being told by IT, be con to be concerned of That they're concerned about data residency and data sovereignty. what do they mean by that, most likely? Tobias Lipsky: Well, if you translate it back to the house analogy that I used, y it's basically we all choose where we want to live, we all choose how we want to build our house and where it's supposed to be located. It's the same with your data and the tools that you're using. So your walls being the different tools from Teams to AI to whatever system you have internally in place, then the room being shaped as how these tools interact with each other. your use cases, is it a living room or is it a kitchen? And basically all of this you can translate it back to the IT discussion. But in the end it comes down to where is your house placed? What's the foundation like? Is it solid? And it's the same discussion in IT. So moving that to sovereignty, it's like what happens if tomorrow somebody flips the kill switch and just turns it off? Can you continue to operate? And these are not new questions, they just get re asked with AI implementation because mostly it's US companies behind it and they have questionable data policies here and there. But adding the whole political discussions going on with Europe, US and everything in the world, everybody's looking again at these core questions. Can I sustain my business on my own? Can I continue running it if somebody turns a tool off? And that goes to data sovereignty. If you basically have a server based in your own country, you assume it's the same legal framework. Of course, it's a server, your data remains in the same company. But then the question comes up: who owns the server? Who operates it? Where is that company located at? And if that's out of your jurisdiction or even outside the EU, taking For example, Amazon cloud services, there is an EU sovereign cloud, but in the end it's still owned by Amazon Inc. in the end, which is an American business, meaning America still has access to this. Microsoft, even asked in court in the Netherlands basically, answered yes, if we get asked or request by the US government to show data, we're gonna have to show Dutch data. No matter what the EU laws are, because it's a Microsoft cloud in the Netherlands, still owned by Microsoft US. So this is the discussion where is my house located in, in which country is it? But if you build a beautiful house but the base is located somewhere outside of your scheme, there's always basically a backdoor open with somebody having access or a key to the door. Giac Soliman: Gotcha. And that probably explains why, you s some IT departments, despite no you having an approved AI tool in the company, they still say, Well, hang on, we're not ready to share personable identifiable information yet because that data is being stored somewhere in the US and there are other forces in play. I think that's what you're trying to say from from your conversation. Tobias Lipsky: But then you also have to relatively if you view it as a pragmatic solution, because if the discussion goes, let's say, on co-pilot and AI and not you not being allowed to implement it fully, let's say your IT department doesn't allow you yet to use these tools, it it's quite ironic. If you're not allowed to use the AI tool of Microsoft, but all of your saving data environment and everything is Microsoft. So you have the downside already of the US having access anyway, so might as well just use the AI too and have the benefits of it. Doesn't make much of a difference. Giac Soliman: Which which goes back to that minefield you were referring to earlier. the risks were already there. The privacy exposure, it came with the data sharing deals that were signed between Microsoft and your company years ago. AI didn't invent any of that, right? So you're you're probably you're not creating a new problem by using an enterprise appropriate approved like a company approved AI tool that lives already inside your company's tech stack. Tobias Lipsky: Exactly. So hence the question when you go going back to what you said, when you meet IT for the first time, what are you gonna ask them? What they're gonna ask you, they're most likely gonna confront you with all of these spheres of we can't implement AI because then US has access. Your best counter argument is well, I'm anyways already using Microsoft and Windows environment, why not also use the AI? 'Cause if you're basically limiting my tool set here now, you need to ask bigger questions. If you can live with the existing risk of access, what changes if you then implement the AI on it? Assuming the guardrails to your neighbouring departments are of course cut. Giac Soliman: maybe the fear is not quite about sharing data with a specific country. if you say you're based in Europe or the EU and you'd be sharing data with the US or China or vice versa. Could it be that the fear comes from who you'd be sharing data with internally. Maybe only a few number of people in the company have actual access to employee data. But once you submit it in the enterprise approved AI tool, there are more people in the company that can have a backdoor to it. Let's say they they don't have access to this data, but if you throw it in the AI, despite being approved in enterprise and all that. it would give them access to to the data that they shouldn't have access to. Is that could that be a case? Tobias Lipsky: Yeah, you're hinting at the the question basically saying, okay, your HR tool, most likely the IT admin in it, is a dedicated, vetted IT admin that is currently maintaining your existing HR tool. But then if you dump this data, even if it's all approved and everything, let's assume everything works nicely into the AI system, that's a different IT admin in the background who might not have been approved for HR data yet. Giac Soliman: Exactly. Tobias Lipsky: So Basically, assuming that there are ways to, of course, guide this in the background on an IT side, but then you need to know that this data was inputted to AI into the company AI system from the HR department. And AI knows this, it knows where the data originated from. So basically, a possible way to approach this is flagging data. Data is anyways flagged today already. where it's located, where it's moving and where it goes and where it comes back. So routing HR data through your AI layer, it will still be known that this is HR department, HR data. Hence, it can also, if there is a maintenance side to be done, that this data set then is internally in the AI backend flagged so that only the IT admin. for HR can access this. And that's the question to be solved that you have with any existing system already in place for your company. AI doesn't make it new. Giac Soliman: Gotcha. I'm gonna surface another word that keeps popping up in these conversations with the comp and Tory Awards professionals that are, concerned about data sensitivity, data residency, sandboxing. Or, why don't you give me a sandbox so I can safely experiment, use AI and employee data at the same time? Could you break it down for us? What is a sandbox and what are the benefits of Tobias Lipsky: I was talking previously about guardrails in place. Basically, a sandbox is the smallest possible unit of a guardrail. So if you have a certain set of data that is super highly sensitive, let's assume you have a sandbox which is called use only for high sensitive shit, then basically you place it in there, do your thing, have the output, and then continue working with the output. But one sandbox next to the other, as in one playground, and Another playground, you can't access each other. You can't get one sand moving to the next box and vice versa. It's only certain outputs that you have pre-leavily defined. And then between sandboxes, you basically can put in another layer that I was talking about previously, which makes your data non-identifiable. So let's say the sandbox used clear names or basically uses the employee number. If the output for the neighboring department it's not relevant which employee number is behind it, as the data gets an output gets moved to the other sandbox, it just gets filtered and the end result is in there. But you're not gonna have employee numbers anymore because the neighboring department simply doesn't need them. They want to know by department, certain KPIs. So all of this gets filtered out. But that's something you're already doing today. So it's not knowing AI again. If you have your Excel spreadsheet and you share it, if somebody doesn't need to know certain tabs on this, you kill them before you send it out to the neighboring department. The head manager will only see the data set that he needs to know, not everything. Giac Soliman: Right. It's not a new issue and equally the need to go to IT to discuss and get approved, that's not new either, right? So so far the questions that I think we touched on, the questions that you as a comp and Tory words leader should ask your T department before, dropping employee data in your AI, whether that's an i with an enterprise license or a personal license. I think the first question is We as a company, do we already have an approved AI tool I can use before I go shopping? This probably you know IT Tobias Lipsky: Yeah, that's your best go. Giac Soliman: IT will probably try to push you towards the tools they already approve because they have limited capacity to vet other solutions. Second question I think we you as a reward person should bring up to IT is The you like defining your use case is of paramount importance. So you'd you'd go to a team and say, here's my use case and here's how sensitive the data is. What kind of data are you dealing with? Is it PII? Is it salary? Is it equity grants? Is it stakeholder or shareholder ownership percentages? Is it MA related data? What's allowed inside of that? And third, where does our data need to live? Right? Do we have servers across different jurisdictions, UK, EU, US? What is our legal position on that? I think we've touched on these three, but there's a fourth one, and feel free to chime in if you if you're identifying one I haven't I haven't come up with yet. Going back to the identification layer. Can we mask identifiers before anything is processed? Instead of using name and surname, can we call employees apples, pears, and oranges? And is that providing enough safeguards for a company? Of course, this is just conversation. It's about potential routes you might want to explore. Not legal advice, but these are the kind of questions that any comp leader might want to think about. before they go and talk to their IT department. Tobias Lipsky: Yes, basically this is what many employees already do today. They have their private AI. Let's say you work in shipping and you have certain use cases that you want dissected or you want to have a new insight or how to structure it, you're gonna basically move this over to a train company, create a similar setting, and then say to AI, propose me a solution, a way forward. So basically, you're in your private AI gonna give data that is completely not related to your business or sector. You're gonna get some insights, pointers, it's like talking to a friend, and then you're gonna use those learnings and then translate that in your own mind back to your use case on shipping. So this is basically already a filter everybody does already today, if they don't have the tools access from their company. Same thing works if your company has AI already in place, and I'm gonna take here Microsoft as an example. There was two versions of Copilots. There is the simple web access, simple search AI, where you can upload files and then it can work with those files. If you don't upload files, it's basically just a Google search box with web access and structures your answers. The other copilot is the copilot 365, which is fully integrated to all of your existing files. It reads them, it has access to them. So if you don't have the second version yet and you want to build something, you can already use the existing company internal AI just like you use your private AI. You translate it away from the security environment and risk and MNA deal that you're currently dealing with or the use case you have at hand. You translate that to a different type of setting, which still begs the same problem, and then you work with that. And then you translate the answers back to your own use case. And this is pretty much something most people already do today. And this is how you can already experiment before you're really getting into implementing the end solution. You want to see if something works. Giac Soliman: Right. I'm gonna shift the conversation a little bit as we get towards the end of the podcast episode. And I wanna focus more on your experience as an AT IT and strategy person. What's that one thing that one question that you would hope people ask you when they come to you? could be a leader from a different department, compensation, marketing, finance, and you're just trying to help them. But they're not either asking you the right questions or giving you the right answer. Tobias Lipsky: What do you actually want to get done? Because most people are a bit scared of the IT department or even their head managers. And in the end, you come to them with a use case or something you want to do. Quite often there is something more behind it, which you actually want to get out of it. It's going to this opposite meta level to say, what is the end result you're looking for? What do you want to accomplish? And then What are you dumping into this as your baseline data set to get to this end result? And this is the key thing to understand for IT and also the managers. So you know how is your data being moved? What are you dealing with? And if it's a quite clear statement on what the outcome should be, it's much easier to target the way to get there. In the end, IT will. Propose you solutions or build a tool or find loopholes or legal frameworks for something that in the end works but doesn't deliver what you actually demanded in the first place. So hence back to your main three, four questions: use case, type of data, tool set already in place. If that doesn't work, which other tool sets are you comfortable with or would love to be using? Yeah. Giac Soliman: Who should sign this off, right? who so know who Tobias Lipsky: that's also a good question. quite often IT will push it up the the ladder and say, okay, unless if this manager here there signs it off, then we're all good. quite often you'll also end up with the head of legal of your firm, which negotiated the contracts with Microsoft, etc. Because if there is just one sentence additional in there that data of a certain kind cannot be implemented because you're not willing to pay for it, that it is limited, then unless this gets changed, you'll never be able to upload your most sensitive stuff. So it's always Giac Soliman: Gotcha. Tobias Lipsky: important to then not just talk to IT. IT will quite frankly fast point you towards the lawyer side of this already. I think the biggest preference on IT side is to be working with somebody who understands already something in IT, who comes not fully without any background, who is like who's prone to understand, okay, this is a complex field, we're gonna be touching lawyer stuff, we're gonna be touching different companies, tools, and how we bring everything together. If this understanding on on the person approaching IT is already there, it's a much better discussion. understanding your own use case and having an understanding for what is possible in IT, this will make it best to be working with your own IT department in the end.