Compliance As A Design Constraint In AI

What was the most unexpected compliance shock you actually faced there?

If you work in the public sector, you abide by institutional and governmental entities. And so the compliance conventions are mostly tied towards FERPA, NIST frameworks, cybersecurity frameworks.

Which role actually is required for or responsible for compliance and compliance-based software?

Technical architect could potentially more easily understand the trade-offs between the architecture it decides to invest in versus the requirements from the industry.

Do you also train your model on synthetic data?

For the most part, yes.

What is the biggest technological pain point you have hit so far? Hi everyone, this is Ambar. I am the co-founder and COO at PureLogix. Welcome to another episode of PureLogix Pulse. Traditionally, compliance is treated as an afterthought, something to check right before product launch. However, in high-stakes AI systems and highly regulated industries like healthcare and education, compliances must function as a design constraint similar to a memory latency or power consumption. To help us explore this, I'm sitting down with Meryll Dindin. Meryll is a serving VP of Product and Technology at Parallel Learning. Parallel Learning provides a digital platform that delivers psychoeducational services and special education to support the student with learning and thinking differences. Parallel has raised more than $40 million so far. Recently they raised $20 million in Series B. Prior to Parallel, he founded a tech startup called Polygon and raised $4.2 million. He's recognized researcher with over 50 citations and in healthcare AI and holds 3 patents for his inventions, including the tech helps that helps doctor detect heart issues. Welcome to our show, Meryll. How are you today?

Great. Thank you for the intro, Amir.

Thank you. Tell us about your startup Polygon. How did you come up with the idea? What problem you were trying to solve?

Yes, Polygon effectively relates to more so of a contextual window of my life. Originally, I'm French, so that's why you pronounce my last name Dindin and not Dindin, which is always funny to hear.

I'm sorry about that.

No, you're good. It's a, I've lived in Japan too, an Asian same story. Um, and effectively moved from a time of my life where I was deeply into AI research for healthcare and always have been in the space of healthcare and artificial intelligence from training to work and then decided maybe what we were doing was not enough. So went to Berkeley at the time to get my first foot in the United States and really truly get a stab at it, at the American dream. And then at Berkeley effectively nailed the technical requirements within 6 months and had to fill it the next 6 months. That brought me to the Haas School of Business, which is Berkeley's very well thought through such that an engineer can do business. That's where I met my co-founders. And effectively, we sat down, like we're just thinking about ideas and things we wanted to be doing in the industry, what kind of impact we would want to provide. And my co-founder at the time came with this personal experience, dyslexic himself, is like going through the process. And so we collaborated into finding whether there was any value there into developing a proper tooling, knowing what the bottlenecks were, following Steve Blank's approach to getting out of the building, getting a sense of what's happening in the space specifically, because the more you get in depth into it, the more complicated it gets. If you're working in the public sector, if you work in a private sector, if you're working direct to consumer, it's all very different. And then we sat down and decided to launch this venture. And that's how the story started.

Awesome. And I read somewhere that at Polygon, you focus on remote ADHD and dyslexia diagnostic. What was the most unexpected compliance shock you actually faced there?

Yeah, so in our space, there are quite a few things. So if you work in the public sector, you abide by institutional and governmental entities. And so the compliance conventions are mostly tied towards FERPA, NIST, frameworks, cybersecurity frameworks, those are frameworks that you can self-evaluate, which is not as strong as if you're working in the private sector, then you have to go through COPPA, you have to go through HIPAA, you have to go through ISO, SOC 2, anything that relates to it. And when it comes to compliance, actively COPPA is the trickiest because in our space, we are at the intersection of healthcare and education. So we do work with a lot of younger children. And so anyone below 13 years old effectively is covered by COPPA. And COPPA is then content collection. It's making, it's a lot of internal training and it's a lot of documentation and audit trails and observability when you build such a product above the operational layer, because you need to train your people and you need to make sure they don't make mistakes. And then you have the technology piece, which is making sure that you collect the information, you maintain it for 7 years through HIPAA. In COPPA, you have to collect all the documents everyone is kind of on the fence of giving you because you need to track consent, for instance. What is documented as consent? You need to go through proper legal counsel to make sure that your text, terms of services, privacy policies, they're all on pace with the concepts. And so working in this industry on a direct-to-consumer, we started Polygon on a direct-to-consumer layer. And so effectively having to work with every single parent. On the basis of consent collection and making sure that we're all protected in terms of— it's so easy to get litigation in the direct-to-consumer layer in comparison to a B2B2C structure like a private school or a public school. So compliance here, the hit was really how much efforts we have had to put into training the people correctly and the sometimes lack of common sense of what is considered PHI or PII from a human perspective., and you would think as a technologist, it's pretty obvious, but it turns out not to be for many. Right.

So when you talk about the compliance and if you're building any startup or any product that is actually, you know, requires compliance, does it actually, you know, slow down the process of building products? Because, you know, in a startup world, there is a saying that, you know, move fast, break things, right? So how does it actually work when it comes to compliance? Like, does it actually slow down all the process?

I want to say no. And the reason I want to say no is that the usually, and you'll get that from legal counsel, depending on your legal counsel, obviously, the stakes are not high, sufficiently high that you take that many risks trying to move quickly. So compliance is an architecture decision, the same way you build a tech stack and you want it to be ready to scale at some point. Compliance needs to be the right upfront decisions such that when you have the time to invest in it, then you haven't shot yourself a bullet in the foot because none of this making sense. So like data structure, it also comes with security basics, security standards, but I want to say that when you build a product with security in mind, it's not more complicated and effectively everyone should be doing it because then we end up with those companies leaking hundreds of millions of information out there.

Exactly.

Right.

So for compliance, so you mentioned that, you know, architectural changes should be at the architecture end, right? So is it more of a job of software architect or do you need to have subject matter specialist or a product owner? Which role actually is required for, or responsible for compliant, you know, compliance and compliant-based software.

Let's say a few years ago was very different than it is today. First and foremost, because a technical architect could potentially more easily understand the trade-offs between the architecture it decides to invest in versus the requirements from the industry. Understanding COPPA and HIPAA and NIST or ISO or whatever of these compliance frameworks It's not that complicated. It's always the same barebone structure when it comes to tech. But the thing is that for compliance, you need tech and people training. And so usually you need someone to come up with the policies, which is text. And effectively, you could argue a legal plugin in cloud could do it, but then you lack the confidence of truly, do you want to base your company out of this? So do you want a legal counsel to look into it? So I'd say someone that is technical with the help of a legal counsel or like a tool like Venta or Dorado, like those tools usually they come with pre-populated policies. Gives you the chance to get set up without the need for a product owner or the need for an expert matter within the company. You'll probably need an expertise to kick in through a legal counsel at some point. It is not as urgent as day zero when you build your company.

Data is very significant, you know, during compliance and building a product, right? So I would like to know more about the data. How do you balance the need for high-quality training data with strict data minimization requirement often found in healthcare and education?

When you say data minimization, do you refer to role-based access? Do you fill in anonymization? Do you talk about— what do you have in mind here specifically?

It could be anything like sensitive information, maybe like, you know, I mean, you cannot have, you know, somebody's chronic disease for training your AI model, or, you know, you cannot have a blood sample or these kind of data that is sensitive, or, you know, compliance require you not to actually share with everybody.

Yes. So It lives in the fine prints of the contract you sign with the third-party providers usually. And so there are two layers to this conversation. There is the DPA or data privacy agreement you have with the customers, your customer, which is usually stating I can't use your data to enhance my services and or depending on the use case or AI forward you are, which is most of those companies right now, it's like I can't use anonymize, I can't use de-anonymized data or identifiable data. I can only use de-identified data to train my models or to better my services. So there's this part, the part about sharing identifiable data is still true. Like usually you commit to not share it. Effectively, it's just you creating your contract and everyone signs it. So that's where the common ground happens. On the other side, and more so specifically for COPPA and HIPAA, then you need to enter the world of what we call like business agreement amendments and BAs. The typical, you sign a BA with Google, you sign a BA with Anthropic, you sign a BA with whoever. Usually it's reserved for enterprise customers. It is very costly. So to that extent, if you want to be very AI forward from day zero in your startup, there is a cost to it. And from that point, then it, all of that architecture decision-making consolidates inside of your data schema. It's what do you call, what do you call identifiable data? It's what's PHI in your data schema? How do you segregate that data from the rest of the data that is not identifiable in itself? Can you use that data to then train models on inference, on regression, on classification, on whatever the task is, and then brings back the model with only the identified data back to your system and your product to provide value? There's nothing preventing you to do it. Effectively, there are many companies doing it. It's just about the boundary between what you call PHI and what you call— what you don't call PHI.

And out of curiosity, do you also train your model on synthetic data?

For the most part, yes. And I'd say it's become very much a way easier today to create synthetic data. Used to be a very painful experience. There are different types of models, right? I've worked on vision models to extract key biometrics from video feeds. Worked on audio models to extract like the speech-to-text conversation, but it's also like vocabulary, utterances, phonemics, et cetera. They're just language data. So like documents that need to be processed. I'd say the vision models, it's harder to get synthetic data. The audio model is pretty easy to get synthetic data at this point. And the text models, like now it's becoming increasingly easy. You can create huge datasets of very contextual scenarios and setups. To create your fixtures, to create your data for training, to create specific use cases you want to reproduce or permutations you would want to make sure are within the datasets to cover future inferences.

Right. Okay. Okay. And I also hear that you built a pathway framework for parallel learning. Could you please shed some light? What exactly is the pathway? How does it actually work?

Yeah. So in our space, we suffer from supply shortage. So it's very hard to find clinicians in our space. So we specialize in special education, and among special education realm, there is a speech-language pathologist, school psychologist, social school workers, or specially designed instructors. Now, because of the shortage, you have to make them as efficient as possible such that you diminish the impact or the feeling that we're lacking people to do the work. And so Pathway has been introduced here, and the same was true at Polygon when we were working on creating reports at a greater cadence. I think at Polygon, we could showcase We're about 8 times more efficient in generating reports and diagnosis and recommendations and follow-ups than a traditional private practice of clinicians. And Effective Pathways is the same thinking, which is we need to create what we call an internal provider operating system to make sure all clinicians are working as effectively as possible from all ends of their duties. So we're trying to diminish all the administrative burden and maximize the true impactful work, which is direct time with the students, with the children. To make sure that they truly focus on what matters, which is making sure those children get the best accommodation, the best learning experience, and the best relationship possible if it's for some form of behavioral intervention.

Awesome. And while you were building the Pathway platform, was there a specific time where a design choice was made purely because the law required it? And did that actually make the product better in the end?

For the most part, yes. I'd say We've had to go through compliance setups mostly for the way you track data and that direct impact on the UX when you build like screens to collect data because you can't show certain things to certain people. There's also a lot of like role-based access control in the way you construct your application. And effectively we have been very security first and very compliance first from the get-go. So now when we go through a penetration test or we go through ISO compliance renewal, it's very easy for us. But now I'm seeing that it has also one beneficial impact I could think top of mind, which is because we've had to introduce this segregation of data through and through and the UX, it's not very easy for us to split the software in multiple verticals that we can either distribute differently or sell differently, which it avoids having a full-on compacted service. And right now we have the chance of being able to kind of split the verticals and offer a certain value proposition to certain customers without having to give them the entire dev platform. And that, that decomposition and that pod structure makes it very convenient and is a direct consequence of wanting to segregate the data and only is the least permission principle in essence.

What are the other challenges actually you are facing while actually building a very high-end UI/UX for these, you know, kids and, you know, teachers who are kind of like laymen when it comes to software?

Yeah, well, when it relates to compliance, it's more like what can you show and what can't you show and what can they edit and what can't they edit. The biggest burden when it comes to compliance is observability. Because in theory, at any point in time, you should be able to tell whoever audits you who accessed what piece of data when. And so when you put some form of data into a screen, you have to be very intentional about what the purpose is, whether it should be shown, whether it shouldn't be shown, and what the impact is on your observability pipeline slash audit logs if you show this information on the screen. If it's a high traffic screen and you show a lot of PHI, that's a problem. So you probably want to decouple UI and UX such that you control the flow of information and no one can take a screenshot or we have those cases where our clinicians, they end up taking screenshots to share information. Then we have to make like a screenshot ready screens, like a demo toggle and like we blur the PHI and they can send a screenshot of the status, for instance. Right.

So do you also like, you know, I mean, share warnings and tips on the screens for these users? Like, you know, this is the information you cannot share. Or simply, you know, like hide the information from those people because I think it's very hard to tell each and everyone.

Yeah, there's a redaction process, like the typical password you show, you hide situation so that you can track the action of highlighting the element. There is the blur option that I mentioned about the screenshot so that you can only share what you're supposed to. And there's training because once again, as I mentioned earlier, it is training the people. So effectively our clinicians and internal employees have to go through training once a year, every year about PHI, about phishing, about best practice in security and understanding what's at stake and that they can't do all of this because that there are legal implications to processing the data at will.

Right. And you're serving as a, you know, VP of product and engineering, like you're seeing both fronts, right? So when you have a cool idea for a new feature, how often does your engineering side have to step in and say like, wait, we can, we cannot do that because of the privacy or security Um, I'd say I'm more on the optimistic side, given I've built companies.

I usually think, like you mentioned before, it's like, we'll figure it, we'll figure a way to make it work. But effectively, there is common sense to be had, especially around privacy and security. There are things I've had to push back in the past because it would mess up or like it would add a new surface for attacks, for instance, and that I'm pushing back. However cool the idea is, or recently I've had to have a conversation where we had this cool idea of having multiple teachers on the same session, different interaction, and one wanted to be there in the background, but then who is in charge, who's the host, who has access to security, who has access to this observer status. And from that perspective, you effectively open a new attack surface, which we didn't want to because that's not something we can afford through ISO compliance and COPPA and NIST and and FERPA. And so there are things like it comes into the mix, but that's it for the most part. Product takes over, like we're small enough and quick enough. And my experience with legal counsel is such that in most cases, you can find a way to make it work.

Does that mean that you can never build that feature even you want to do that in the future?

No, I mean, it means you can. It's just like, is it worth to invest now in standardizing or restructuring the surface at Like, do we want to introduce this attack vector now and monitor it? Or do we want to postpone because we have a better architecture display coming in 6 months because of XYZ project, for instance? And so there's more managing the expectations, and that's the whole duty of a product person is like expectations, roadmap, timeline, and making sure everyone's on the same page. Cool idea, can do now, but can't do in 6 months, and we can think about it further in the meantime.

Do you also train your engineers and also product designers about the compliances all the time? Like, you know, there are training programs.

I'm sure that training programs are going on.

For those guys, like, you know, but who is more important for training, like product guys or engineering side?

I can't say, I wouldn't say one is more important than the other. Because at Parallel, we work on a very decentralized structure. So engineers sometimes end up being product managers and sometimes designers, they end up being contributors. Like AI made the switch quite drastic. And so we end up in a situation where, all of them need to be trained because all of them need to be catching up the gaps effectively. So I find myself sometimes saying, hey, you can't do this, or this will lead to this problem. But this would be generally more so second order or third order effects, not like first order. I think everyone, once again, to me, security is generally common sense, right? More so than it is needing like hardcore training. Right.

And as you integrate more AI into parallel ecosystem, what is the biggest technological pain point you have hit so far?

Technological pain point. Yeah, I think the, well, the painful experience, I don't know if it's an irresolvable problem, but the painful experience is really investing heavily and from the get-go into your observability pipeline to maintain map knowledge structure, but also for sake of security, because that's very costly when you have to map up all your VPC interactions, you have to ensure all your SSH connections are probably, you have a threat, advanced threats management, you have a like all of that, all of that setup, which to me is very much secondary that needs to be put in place to ensure compliance. That has been a pain point for the most part. So coming and setting it up, not nice for tools like Vanta or Drada that help you with like a checklist and then Cloud, Cloud or Codex or those are tools that are pretty good with DevOps in general. So they'll help you with checklists. And like, if you go with infrastructure as a service, it's also very convenient. But to me, that has ended up being the— it feels like redundant. It feels like something you need to invest in for sake of having it and checking the box for compliance. And you understand it will be helpful the day you have a problem, right? But usually you don't have a problem. And so it's really like this investment, like the ROI is tricky when it comes to this. Is it worst case scenario preparation?

Right, right, Rocky. So are you saying that, you know, inducting AI is actually, you know, like costing you more than giving you benefits or, you know, the ROI is not much. At this stage?

No, I'd say right now, well, I'd say right now we're still in the pretty much R&D phase because the company is still pretty young and the value proposition, they come with immediate quick wins, but the longer term evaluation of the value proposition is always the value is tied to what the customer is willing to pay. And it is the value we're delivering through AI and all the follow-ups that there is to it with compliance and data segregation, monitoring and observability and like LLM spans and where do you store all this information to be able able to replay it. All of that right now is a higher investment than the return, but then we haven't yet truly invested in the proof points with the customers and the market, which that's where it becomes interesting is when you truly get a sense of return.

How do you cope up with the problems like AI actually comes up with its own problem like AI hallucination and, you know, eval and these kind of stuff. So how do you cope up with these problems?

I think I'll be saying observability quite a lot, but there are many situations, like for instance, we are based out of Gemini models. We develop with Claude, so we're Anthropic and Gemini, and we have a, we use Codex too, independent of that.

You're using everything, Claude, Codex.

We're using everything. Yes, all the good ones. And effectively, like Gemini just released 3.5 Flash. Yesterday announced it. And so now we all working on top of our prompts to see the results of 3.5 Flash. You can only do that and transition that quickly if you have a test pipeline in place. A test pipeline in place for AI is, is the one that will tell you you're taking care of hallucinations for the most part.

Right.

It's this notion that I have is the same as a unit test. It's a fixture. This is the original data context I have. This is the output that should be able to parse through, whether it's structured or unstructured, you have two ways to evaluate. And that gives you like a sense of accuracy, F1 score, sensitivity, recall, whatever you want to go through. And that is how we work through our prompts and the rules and the don'ts and the dos, such that the system, the prompt engineering that goes behind it is hallucination prone or is avoid of hallucinations. Now you're never going to catch them all because it's always like people are very creative in the way they prompt AI. And so the more you, if you offer an AI tool to someone directly as a conversational agent, then you are facing the issue where you're not in full control of the conversations. And for that matter, we have our own internal AI agents. We're working on external AI agents, conversational. And so that's where we make a distinction between agent tools and skills and always provide whatever the situation that And we might go in more depth into mitigation there, but whatever we do, we always have the ability, we provide a feedback surface for our users, thumbs up, thumbs down, follow-up messages. And then we have our own evaluation of the pipeline, which is a Consul audit structure, which is using different models for trying to answer the same questions and compare all of them to see who is wrong and who is right. And that gives us like a replayability and that replayability gives us the like some form of accuracy over the pipeline and thus tells us statistically this model or this prompt or this agent version is more susceptible to provide an hallucination when it needs to do a data query, when it needs to provide knowledge data from or help desk center or whatever it is. And so that's how we monitor it right now.

That's a very robust monitoring system, I would say. Yeah. So just wanted to ask, like, you know, you, it seems like you guys are actually heavily focusing on AI internally and on your product, right? So does that actually affect your recruitment too? Like how, what sort of engineers you guys are hiring? Mostly like, you know, the one who actually are good with the prompt engineering, the one who is actually problem solver.

This is a, this is a question I get a lot. I think being a founder, I got a lot of founder friends now reaching out to me. It's like, what do I hire today? Hiring today is extremely complicated, honestly, because my perception of the true engineer right now has disappeared. There's no such thing as a true engineer. Is what I would call a full-stack builder. And so those are the people that can do product, they can do UI, some full, they can do UX, they can do full-stack, they can do back, front, security, they can do all of it from idea to production and collect the feedback from the people because effectively it's just soft skills. Obviously all of them will have a signature, like a color as I call them. It's like they either better backend, they're better UX, they're better UI. They will have this form of like, web of skills in, in, in many different colors. But when you evaluate them, or when you hire them, or you try them, when you have this conversation, it's very hard to evaluate whether someone can do it all or has the holistic perspective. And I'd argue that with AI right now, you're looking at people, there's a, there's a sense of orthogonality that's popping up, which is either you're hyper-focused and you're very good at your craft and you can go very much in depth and then you'll be enhanced with AI as you go through, but then you need, your company needs a very hyper-focused product space or vertical that it needs to go through. Or as a startup, you actually don't want this type of profile, I'd argue, and you want more so that everyone acts as some form of manager. So parallelization is, and concurrent action is super important because then you can explore many ideas at once and you can focus your attention on multiple agents and work through the development of many different ideas that you want to stress test. And that drastically enhanced the velocity of your company in testing ideas and collecting feedback and determining whether this new vertical is worth selling. When right now I'm having an interview with an engineer, what I'm testing for is self-skill.

Okay, great. Thank you so much, Meryll. Thank you so much. You made a really tough topic sound easy. It's great to see that you guys can build cutting-edge AI while putting safety and rules first. Thank you so much. And for our viewers, stay tuned for the next episode. Thank you. Thank you.