133 Develop An AI Usage Policy in your Accounting Firm

Okay. More than 80% of accounting firms still do not have an AI acceptable use policy doc. It's. Pardon me, man, we got to put these docs together to liberate our teams. They're not restrictive. You're defining the boundaries so that they can go absolutely wild within those boundaries. Man. Laziness is the mother of invention. And if I'm running a firm, I want to get these tools into my team's hands so that they can figure out ways to use them, figure out ways, use them to be more productive. So we're going to talk about that today, how to framework out your own policy doc and work through some of those spooky, scary. So come on in, let's talk about it. All right. Should go without saying, I'm going to give you kind of a framework for how to think it through this methodology. But absolutely. Talk with your insurance carrier, talk with your IT company, whoever you use for support. But there's absolutely 100% secure ways to do this stuff today. And if they tell you that there isn't, they are wrong. So I'll run you through my framework for how to think through this policy doc, and then we're actually going to pull in. We've got a. We've got a co host that's going to kind of help us think through maybe some of the things about this that make us scary. So why don't we actually just. I'll introduce you to the co host real quick. This is Nervous Ned. Nervous Ned is the embodiment of the spooky scaries of something new, you know, and how kind of like back in the cloud accounting days, it was just hard. It was just hard to think through this stuff. Hard for it to. I don't know, it just took a while for it to be normalized. So let me introduce you to Ned here. Gonna ask him in general what his thoughts are on using large language models to be more productive.

Whoa, whoa, whoa there, partner. Before you go galloping off into the sunset of innovation, let's pull on the reins a bit. Now, I get it. Everyone's talking about these large language models and whatnot, but remember when everyone was raving about that new fangled calculator and I was like, my abacus works just fine, thank you very much. Now, I'm not saying progress is bad, but using client data with these models, can you imagine? One day you're tallying numbers, and the next, who knows, Maybe your AI will decide to pen a romantic novella with your balance sheets. But hey, I'm just A certified public accountant. And oh, did I mention that lovely frame certificate I have? It's right by my desk next to the plant. It's quite the conversation starter. Anyway, I'd say take it slow. These new tools might sound flashy, but sometimes the tried and true methods work best. But what do I know? Just a guy who loves his spreadsheets, old movies, and a nice cup of Joe.

Okay, okay, that was Nervous Ned. We're gonna use Nervous Ned as a sounding board for some of our more progressive thoughts to kind of think through this. Judging by what we've heard so far, I think Nervous Ned is a fan of analogies, which is oftentimes what people use to like spook us away from doing something, rather than like first principles. How does this stuff actually work? Okay, so as you're thinking through this policy doc, we're going to talk about the three different types of information, three different types of info that you put into language models. And then specifically when it comes to the tools themselves, how we set those up to be as secure as possible. And so AI is a bunch of things you use tools every day right now that use AI specifically. What we're talking about is like chat GPT1 working with language models. How can we do that sort of thing responsibly? So three different types of information and with each there are kind of different security concerns around each. So let's talk about non sensitive information, let's talk about redacted sensitive information, and let's talk about just straight up sensitive information I.e. client data, stuff that is identifiable. Maybe it is like internal, internal company secrets, because we got a whole lot of trade secrets in accounting. But first off the easy one, stuff that is non client related at all. So let's say I'm going to generate a blog post. Let's say I want to ideate like a better name for a blog Post or a YouTube video, think through some concepts for like something that I could post on social media. Honestly, the vast majority of the stuff that I think we probably go to the language model for is actually not related to our clients or, or even our firms so much at all. And in my mind that can extend to stuff like, you know, generating different ideas for the copy on your website. Oftentimes what we do on this podcast, we have it generate some micro niches and then we have it generate like some panes that are hyper specific to those micro niches. Stuff like this ultimately isn't related to our, like our clients identifiable people and businesses. And this is the easiest Thing to open up. Like, there's, there's an aspect of setting this firm policy in a way that is, I don't know, like a stance that your firm takes. But right now, around non sensitive information, there is no reason we ought to be slapping anybody's hands away from using language models for like non sensitive information. And this, like we ought to define this in the policy doc. And so in the question of first, what type of information is it, which of these three things to then second, which is where am I using it, what tool and what are the underlying settings of that tool? Step two, like doesn't even matter with this. You can chuck this in chatgpt. Like doesn't matter because it's not sensitive information. And it can be a helpful exercise for you. And maybe if you run a team, you do this in the context of a meeting of people, giving very specific examples of, well, what is non sensitive versus sensitive, redacted versus sensitive. It's worth building out like a big example list of stuff that is non sensitive. Like we talked about, you know, blog posts, website copies, social media stuff, anything that doesn't reference a specific client or something you're doing with a client. I would probably put like emails if you're generating emails or rewriting emails. I would probably put that in sensitive, redacted or sensitive if it references the client themselves. But it's probably worth thinking through a big old list of things that are just non sensitive. Everyday uses for this, like generating a script or a macro for this little thing that you're doing in Excel or troubleshooting an Excel formula, stuff like that. And it all gets a little more blurry when we go to the next type of information, redacted, sensitive information. Now part of what makes this hard is there's so many different, like governing bodies who will give you their own definition for what sensitive information is. I can tell you in general under like GDPR, under HIPAA's rules, under California's privacy rules, if you have something that is otherwise sensitive that is redacted to not be able to be identifiable to any individual or a business, it is generally under, under all those rule sets, it is not sensitive information. You can go out and you can look, you know, GDPR rules around anonymization and pseudonymization. That information generally isn't, isn't considered sensitive. And it's why you see all these news stories about, you know, all of your medical data being sold to Google. They're not selling Jason stats as medical data. They're selling anonymized information because there aren't the same restrictions on around that anonymized information. Now, is it okay to plug that stuff into a language model? This is probably an area where it's going to be a decision of the firm. And so to use a really specific example, let's say you've got a set of financial statements and you just remove the company's name from those financial statements you remove. You know, if there's anything in the, in the account names that are specific to an individual or anything like that, you remove all that and you chuck it in the language model to do some analysis. Is that inbounds or out of bounds? That's for you to decide. For me, I don't think I have a problem with that, just on the grounds that it can't be related to a specific individual. This episode is sponsored in part by the fine folks at Client Hub who are building some super rad AI stuff into their practice management platform. And I want to, I want to tell you about stuff that they've actually got. It's in there, it's happening. When you look at emails inside of Client Hub, you're going to get an AI summarize thread like, like a summarized, shortened version of your long emails. They're writing an email and you just, you. Maybe you're a little hangry. Maybe it's just. Maybe it's just one of those days, you know, Client Hub is going to help you revise the tone of that email into something that will. Let's just say something that won't come back to haunt you in the future. Future. More stuff they got in the works. Magic. Magic meetings. You ever been in a magic meeting? Meet with clients inside of Client Hub and it will capture the transcript for you. So it is right there alongside your files and everything else. They're also working on generative email that can see into the replies, the past conversation and magic answers. A lot of sorcery happening. Ask Client Hub for anything related to a client. Client Hub will answer it based on all the context that it's got. Your meetings, your emails, your notes, your files. That is the kind of sorcery I can get behind. Love to see him investing in AI. You want to learn more about Client Hub, check out the link in the Show Notes. This episode is sponsored in part by Copilot. Is your client portal just a portal or is it a platform difference? With a platform, think of something like QuickBooks. You can plug a bunch of other stuff into it, right? Like it's like we got this thing it's pretty cool, man. It can do some stuff, but we're also perfectly happy to let you build more stuff on it, to let developers build other stuff on it. That's the difference in Copilot's approach. They want to create just that, just that candy coating around your firm, Just the layer that talks with your clients, not all the other stuff. Just the frosting on the cake. They're going to handle that part in a way that will be flexible long term and ensure that your clients have not only the very best, most seamless experience possible, but also like, they have all of that stuff in one place. You don't have this fragmented experience where they're having to like log into this and magic link into that and go all these different places. Right? Like, nobody likes that. It kind of makes your firm look silly when their clients are like, why can't you not just have everything in one place like my utility provider and the library? And you're like, it's complicated. Okay, well, Co Pilot's taking a kind of a different approach and holding themselves out as a portal platform. Got APIs. You can actually develop your own stuff on top of that platform if you want to. It's interesting. And they got a whole bunch of accounting firms running on it now too, if your firm's missing that candy coating. Learn more about Copilot Link in the show notes. And just zooming out like, we're still very early days on language models and kind of kind of building this like consensus around what is okay and what is not okay. Like, and I think we, we like to think of language models as almost like this database where it, like, it isn't that if something is trained into a model, unless the company is, you know, saving copies of those prompts or something like it, it's not something that is ultimately retrievable. If we think about examples in image generation models where you could plainly tell like, oh, that was like a copyrighted Gettys images, you know, image or something like that. Or there's been was news stories of, you know, like medical. A medical image where a person could tell like that was their medical image or it was part of their medical IM or something like that. Oftentimes those spooky stories can scare us away even from putting like redacted information into a language model. And ultimately this is something that you have to decide for yourself. But at the end of the day, is that thing going to be retrieved verbatim somehow in somebody else's discussion when we're talking about a language model that's trained on billions of parameters and even if it did, it wouldn't identify anyone specifically. Is that a big deal? Probably doesn't feel like that to me. But this middle type of information, redacted sensitive information, this is probably the biggest thing where it's like, you just need to make a policy decision and if you want to be cautious for now, that's totally fine because even a cautious version of a policy doc today is better than absolutely nothing. Let's get Ned's take. This is definitely one of those, it's a new spooky thing so people like, kind of, well, panic about it and just say like, oh, no, we're just going to totally block that off for now because we don't understand it yet. When actually the rules around like, and the disclosure of how information is retained into a model, unless you're using like fly by night models on the models we talk about like, like GPT and cloud and stuff like that, that is very explicit. Like, we completely understand how information is introduced to those models and whether it's retained. There is no ambiguity about that. Let's ask Ned. What's your take on whether we can use redacted client information when working with language models since it's not generally considered sensitive information?

Whoa, whoa, whoa, slow down there, speedster.

Whoa.

I feel like you're trying to put racing stripes on a horse drawn carriage. Now, while redacted information isn't always considered sensitive, have you considered the potential pitfalls? Let's say, hypothetically, one small detail slips through and voila, someone's cat's name becomes the talk of the town. Sure, redacting data sounds peachy in theory, but to quote an old movie I watched the other day, just because you can doesn't mean you should. Remember, I've been crunching numbers long before these fancy models came around. Got a certificate to prove it too. But I digress. My two cents. Play it safe, stick to what we know, and always double check your work. After all, if you've seen one redacted document, you've seen, well, mostly all of them, I guess. Stay zesty.

Zesty. Okay, cool catchphrase. Okay, there, I mean, there was a nugget in there, right? That was interesting. And maybe this is a rationale for not allowing redacted sensitive information to go into language models on your firm. He says, let's say hypothetically, a small detail slips through. Is that a rationale for not doing it? Honestly, it's a pretty good argument. Like maybe now I will say with models with GPT specifically they anonymize the prompts that are trained into the model. Do I ultimately want to rely on their automated means of anonymizing information? Probably not, but that is a pretty fair argument. I didn't realize this was an old person. He alluded to having done this for a long time. Also stays SD is a nice touch. It's probably where you just got to use discretion and make your own decision for your firm. Now very the second step there of like what are the tools that it's going into and which ones are okay and not okay. You've got a spectrum of how configurable these tools are from a security standpoint. And the good news is stuff has gotten way better from the early days and we're getting more and more privacy controls. And so on the ultra secure end of the spectrum right now you have Bing Enterprise Chat and if you use Microsoft 365 you almost certainly have access to this whether you realize it or not. The only people that don't are the ones on like the most we baby like Starter Business plan. And so Bing Enterprise Chat the way it works, none of the prompts are used to train the model. And that's the one big language model specific thing you got to look out for is are the prompts used to train the model and make it better. And all the prompts that are sent and are used are retained within your organizational data. So it never leaves the bubble of how Microsoft kind of encapsulates your firm's information. And while Bing Enterprise Chat is far from the best model right now, it is super secure and so that's great. On the other hand, if we look at ChatGPT for example, ChatGPT, by default your prompts are used to train and improve the model. And this is something specifically you want to define in your policy doc. Inside of ChatGPT there is a setting that can disable this. It is a privacy setting where it'll no longer remember your conversations so it won't show them on the left hand side like your past conversation history. But if you enable that privacy setting, the prompts are not used to train the model. And so this is kind of a two step process of what are the allowed tools to use and what are the types of information. Because if you combine something like okay, we're going to redact anything. And so that's the second type of information. But then also you can use it with ChatGPT with the privacy setting enabled. We're now combining the fact that that information is redacted, but also it's not even retained in the model at all. So is that okay? So I think when you're thinking about this policy document, you're thinking, for each class of information, each of those three types of information, what are the acceptable uses of that? So information type 1, not secure at all. Feel free to use that in anything. Information type two, you might say, this is okay to use in Bing Enterprise Chat and ChatGPT with the privacy setting enabled. It's worth thinking through it in this level of detail. And then type of information number three, you've just got straight up sensitive information. And there shouldn't be very much of this because it's very rare that you have a situation where information can't be easily redacted. So like a set of financial statements, for example, you just remove the company's name. You got an email to a client, like remove anything that's identifying, like the client or the business name. So it's pretty rare that you're gonna have something sensitive that couldn't be redacted. But, but it'll happen sometimes. So maybe it's like, you know, a big old Excel file of ledger history where it's like, are you realistically going to go through every single line of that and ensure that there's no company names and all of that? Like, probably not. But when this does happen, you can still define what acceptable uses are. And so, for example, if you got Bing Enterprise Chat, it's probably fine to do that. Like, that's the whole purpose of that language model. And the way that Microsoft holds it out is like, finally, an AI chatbot with, they say, commercial data protection. So for sensitive information, you might say you're totally fine using that with, you know, Bing Enterprise Chat. Maybe you're going to say it's okay to use that with ChatGPT as well with the privacy setting enabled because it's not trained into the model. The other most common model that folks are using is Claude. Unfortunately with Claude right now, I don't believe there's like a private mode. And so that ought to be okay. With non sensitive information, you, you would have to use your judgment on whether that's okay for redacted information, but for sensitive information like Cloud's definitely not the solution. This episode is sponsored in part by the fine folks at Cloud Accountant Staffing. Do you hire accountants? Bless your little heart. Not the best part of the job, in my opinion. Not something I ever enjoyed. Well, listen, you can build your accounting dream team with talented offshore Accountants in the Philippines that work 100% full time for your firm. Their accountants aren't freelancing or contracting for multiple firms. They're all yours. They work exclusively for you and are incentivized to stay with you and your team long term. They're not going to get swiped. Cloud account staffing is 100% dedicated to the accounting industry and founded by a former accounting firm owner that understands your business, knows your pain points. They had to hire some accountants and they said, you know what, we're going to build our own pipeline in the Philippines, going to pull in some super talented people and then open that up to other firms. Basically that's the story. I've been talking about a lot about staffing, building more resilient staffing pipelines for your firms. I had staff in the Philippines at like totally red pilled me to like oh geez, like we need to globalize the way that we get our work done. Check these folks out. Link in the show description cloud accountantstaffing.com now on the tool side, that's step two. One variable that we have kind of coming into the mix now is these sort of internal copilots. And so Bard was the first one to release a meaningful version of this. It's basically their version of Microsoft Copilot. Bard now can see into all of your Gmail and your documents within your workspace and all of that stuff so that you can chat with it about all of the stuff that is there in like a secure kind of self contained way. Microsoft Copilot November 1st just around the corner for enterprise users. I don't know how capable that model is going to be on day one because right now Bing Chat is not great. But as you're thinking about this usage policy and how it evolves, Microsoft 365 Copilot is yet another tool where you can define acceptable uses. And this is going to be a very secure one that you ought to be able to put just about anything into now if its capabilities are weak, you're still going to have people wanting to go out and use other models. So for example, Chat GPT's data analysis model right now, man, you can check financials, ledger history. You can do all of this stuff in this data analysis model where everything else like Bing Enterprise Chat, Claude, like these are just like text models where you just chat with them. The ability to upload an Excel file to a data analysis model in ChatGPT, that's pretty novel and that's really the only place that you can do something like that. So there's still absolutely going to be solutions. Let's say we get Microsoft 365 copilot on November 1st and then we're like, oh great, now this can like make all of our AI dreams come true. Reality is it won't and we're not sure the quality it will be when it comes out. There will pretty much always be novel functionality with other AI models that can absolutely save you time. And this is where this large language model policy doc can basically give you the ability to approve the usage of certain types of apps with specific settings for certain types of like, sensitivity of information. Now we all have a nervous net inside of us that says, should I just, should I just wait? The main risk of waiting is you're not giving your team the opportunity to begin learning how to use language models and get the most out of them. I save a massive amount of time and we've talked about things as simple as getting structured transaction CSVs from a bank statement. And like GPT4 will do this flawlessly. But that's an example of like redacted sensitive information. And ultimately what is going to lead to the most learning is like unleashing people, like letting them try to use this stuff to make them more productive. Because for me, the best ways that I've used these language models was in personal productivity applications. The kind of stuff that there isn't an app to do. For me, it's like this fiddly little thing I got to do for a client or every single month I got to get this report in this PDF format and then convert it to a CSV to import into this other system. Like man language models are so good at that kind of thing. And how many of those fiddly little one off tasks do we have that a language model can help us with? That ultimately, I think is the value of trying to set people free by defining the boundaries. But there's a bit of like mental processing we gotta do here to kind of work through the nervous nets. So I'm gonna ask Ned here. What are your thoughts on folks trying to be progressive with defining the boundaries of the. Okay, the approved usages of language models.

Whoa, whoa, whoa. Put the brakes on, buckaroo. Pushing boundaries sounds like someone's trying to make their horse do a tap dance.

Lot of horse stuff.

Look from where I'm sitting, right next to my framed accountant certificate. By the way. Progress is great, but with sensitive info that's like juggling flaming torches while riding a unicycle. Sure, it's Entertaining, but it's also a one way ticket to Oopsville. We've got to remember that some things are best left untouched. I say let's keep our socks on and tread carefully. Always better to be the tortoise than the hare when it comes to sensitive matters. Keep it snazzy.

Okay, I don't. I feel like this is what people actually do a lot, and this is totally absurd, but people love to use analogy to prove a point. Okay, one way ticket to Oopsville. I. Okay. Ned has made a. Has made a legitimate argument against the redacted sensitive information approach in cases where. In cases where that prompt is trained into the model. Right. If you got a totally secure way to work with language models or if you got a privacy setting, I think that's still a lot more inbounds. But the reality is this stuff's getting more secure every day and we're getting more options and functionality to let us work with this stuff securely. Securely. Like this is an inevitability that we can do this stuff securely. I want to get Ned's take on if this is inevitable and we already have secure ways to do this now. Like, why? Like, why would we? Why would we not?

Whoa there, turbo. Secure today doesn't always mean secure tomorrow. Just because my gramophone still plays those old timey tunes doesn't mean it's ready for a rock concert. Sure, technology is racing ahead and there are secure ways now, but completely secure? That's like saying my favorite flannel shirt is forever in style, though. I swear it is. It's always wise to approach with caution, especially in the world of numbers and sensitive data. Remember, even the most robust vault can have a rusty hinge. Stick with me and we'll navigate this brave new world together, one spreadsheet at a time. Stay spry.

I don't know why he's got it like a cat. Different catchphrase at the end of each statement. Secure today isn't secure tomorrow. I don't. I don't know. And the whole notion of, like, can it really be completely secure? About a dollar for every time I've seen that on social media. That's a really easy thing to say, but I think lazy, because ultimately we can push back on that and say, okay, specifically, what. What are the concerns? And the most common thing I hear is, well, we don't really know what AI can do. And it's true. This is a thing called capability. Overhang the notion that language models are capable of things that we haven't yet discovered. But what that doesn't mean and what that shouldn't cloudy. What cloudy. What that shouldn't confuse is how information is retained in the model that we know that is very explicit. And there's. I think it's easy. Some people like to like cast this doubt over AI companies in general where it's like, oh, they do AI stuff, so can we really trust them? It's like we're talking about something like OpenAI now an 80 plus billion company. But we will trust our sensitive information to like tools inside of our space that are very small companies with less than 10 employees. I've always felt that the and I felt the same way in the cloud transition. The kind of knee jerk reaction and the wait and see. Like I think it. There's a degree of laziness to it and we really need to focus on getting explicit about what is the blocker and what needs to change until it is okay. And really the only thing different about language models is whether or not the prompts are trained into the model. And this is something that we know across like these mainstream models. There is no ambiguity there. Let's see if Ned has any like parting wisdom for us. How do we balance like being progressive and trying new stuff and making the most of this for our clients without like getting out over our ski tips?

Partner, you're juggling quite the conundrum. Balancing progress with caution is like teaching an old dog like yours truly new tricks while making sure he doesn't tumble off the porch.

Something's happened to me.

Knowing your limits. Just because I can dance the jitterbug doesn't mean I should bust a move at every soiree. Dive into new technologies, but always have a safety net. Test the waters before diving deep. Secondly, listen to your clients. If they're hankering for a high tech hoedown, maybe give them a taste, but always be clear about potential risks. Lastly, rely on the basics. My framed CPA certificate didn't just appear overnight. There's wisdom in traditional methods. Marry the old with the new and you got yourself a recipe for success without overreaching. Now let's keep this rodeo rolling at a pace everyone can enjoy. Stay sharp.

Okay, I feel like Ned went a little sideways there. Okay, so we're using GPT4 and like a definition of a character to generate this text and a tool called 11 Labs for the Voices. Ned got a little unhinged there. Actually pretty darn good advice. He said. First, it's about basically knowing your limits. I think was the gist of it. Not getting too far out ahead, man. That's good advice. Even if you want to think progressively, that is good advice. Second, he said, listen to your clients. Honestly, that's maybe part of the discussion that we've totally missed. How do my clients feel about this? Like, what is my client's appetite for me leaning into AI responsibly to their benefit to help me be more productive? We don't all have the same client bases, and a lot of us probably have client bases where right now they're like, heck no, man. Whereas, like others among us, our clients are going to be like, absolutely. Like, put that stuff to work. Stop wasting time. Don't make things any harder than it needs to be. And then third, something along the lines of marrying the old and the new. Honestly, nervous Ned, not bad advice. He made me a little change of verse for my liking. Also a lot of horse stuff, and I think he even said something about a rodeo. But not bad advice there. So I would encourage you do the work of putting together a document, even if it's super basic, super high level. Get your IT companies take. Get your insurance companies take. I guarantee you, if you run a team, they're using this stuff in some capacity, whether they're supposed to or not. So we absolutely need to set the boundaries there because what it does is it ultimately gives, like, responsible permission. That's what we want to do, is give people the tools they need to do their jobs as efficiently as they can. Now, if you got thoughts on this, honestly, I would love to hear them. And the best way to put together a policy doc and all that. Drop it in the comments. I think this is a really good discussion, an important discussion to be having right now. How do we do this stuff responsibly without the nervous Ned kind of taking over the conversation? Right. That's all I got for today. Thanks for coming and hanging.