My guest this week is Kevin Killens, CEO of AHvos, a technology service that provides AI solutions for data-heavy businesses using a proprietary technology called Contextually Responsive Intelligence (CRI), which can act upon a business's private data and produce results without storing that data.
In this episode, we delve into this technology and learn more from Kevin about: his transition from serving in the Navy to founding an AI-focused company; AHvos’ architectural approach in support of data minimization and reduced attack surface; AHvos' CRI technology and its ability to provide accurate answers based on private data sets; and how AHvos’ Data Crucible product helps AI teams to identify and correct inaccurate dataset labels.
Topics Covered:
- Kevin’s origin story, from serving in the Navy to founding AHvos
- How Kevin thinks about privacy and the architectural approach he took when building AHvos
- The challenges of processing personal data, 'security for privacy,' and the applicability of the GDPR when using AHvos
- Kevin explains the benefits of Contextually Responsive Intelligence (CRI): which abstracts out raw data to protect privacy; finds & creates relevant data in response to a query; and identifies & corrects inaccurate dataset labels
- How human-created algorithms and oversight influence AI parameters and model bias; and, why transparency is so important
- How customer data is ingested into models via AHvos
- Why it is important to remove bias from Testing Data, not only Training Data; and, how AHvos ensures accuracy
- How AHvos' Data Crucible identifies & corrects inaccurate data set labels
- Kevin's advice for privacy engineers as they tackle AI challenges in their own organizations
- The impact of technical debt on companies and the importance of building slowly & correctly rather than racing to market with insecure and biased AI models
- The importance of baking security and privacy into your minimum viable product (MVP), even for products that are still in 'beta'
Guest Info:
- Connect with Kevin on LinkedIn
- Check out AHvos
- Check out Trinsic Technologies
Privacy assurance at the speed of product development. Get instant visibility w/ privacy code scans.
Shifting Privacy Left Media
Where privacy engineers gather, share, & learn
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Copyright © 2022 - 2024 Principled LLC. All rights reserved.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Kevin Killens (00:00):
I think that it's very important that, as the
world grows increasingly moreconnected, that the connection
is isolated to what we giveaccess to, not what we put
online.
I think there's a bigdifference between what we
actually agreed to give peopleaccess to and what they actually
(00:20):
access.
I'll give you a perfectexample: if you look at the
EULAs - the End User LicenseAgreements - no one ever reads
those.
They're so long and obfuscatedand companies do that on purpose
so that you don't read them.
Debra J Farber (00:33):
Hello, I am Debra J Farber.
Welcome to The Shifting PrivacyLeft Podcast, where we talk
about embedding privacy bydesign and default into the
engineering function to preventprivacy harms to humans, and to
prevent dystopia.
Each week, we'll bring youunique discussions with global
privacy technologists andinnovators working at the
(00:54):
bleeding- edge of privacyresearch and emerging
technologies, standards,business models, and ecosystems.
Welcome everyone to ShiftingPrivacy Left.
I'm your Host and residentprivacy guru, Debra J Farber.
Today, I'm delighted to welcomemy next guest, Kevin Killins,
CEO of AHvos.
(01:14):
AHvos specializes in AIsolutions for data- heavy
businesses.
In a strategic partnership withTrinsic Technologies, AHvos
offers exclusive cloud hostingfor its private AI engines,
allowing businesses to havetheir own dedicated AI engines
powered by their own data.
According to Kevin, what setsAHvos apart is its proprietary
(01:36):
technology called 'ContextuallyResponsive Intelligence,' or CRI
.
Unlike traditional AI modelsthat rely on 'Large Language
Models' (or LLMs) and heavyneural networks, AHvos CRI
technology can act upon abusiness's private data and
produce results without storingthat data.
I'm really excited to divedeeper on this technology and
(02:00):
learn more from Kevin.
So, welcome Kevin.
Kevin Killens (02:03):
I appreciate it.
Thank you very much, Debra.
It's great to be here and lookforward to our session today.
Debra J Farber (02:09):
Excellent.
So, obviously, to start, Ithink it would be really helpful
for you to tell us a little bitabout AHvos t hat motivated you
to found this AI focusedcompany, and a little bit about
what your career trajectorylooks like?
I know you were in the Army orNavy.
You were in the military, right?
[Kevin (02:26):
Navy] Awesome.
Tell us a little bit.
Kevin Killens (02:31):
I was in the Navy .
This company is a very personaleffect for both my partner and
I and we're dedicated to it fora variety of reasons, obviously,
but we saw that there were alot of companies out there that
were performing AI and coming upwith various models.
Two things stuck out to us (02:50):
1) One was that the change in AI
was really not that significantsince the mid-century, last
century.
The main advancements that weremade were hardware and the
amount of digital data that wasavailable.
So, my partner and I said,"Okay, there's got to be a
better way of doing this.
(03:12):
So we started to look into itmore deeply, and the main reason
that we focused on it was thatwe both have family members that
had medical issues.
We wanted to find solutions formedical issues, and that's the
reason why we started workingwith the models that we have
(03:33):
with our engines.
Because those medical issueswere so personal to us, one of
the key elements was that themedical issues that we had
family members experience werenot very common medical issues.
We all know pharmaceuticalsfocus on the dollars, and so
(03:59):
smaller issues were not thingsthat they would place a lot of
heavy emphasis on.
So, we decided that we wouldcome up with a system that we
could address both the largelevel medical issues but also
the smaller, more niche or morerare conditions.
That's what kind of prompted usto start it.
As we started moving down thepath, we found that there were a
(04:23):
lot of commercial applicationsto what we do, and so we
obviously started working onthat path as well.
Our ultimate goal is to be ableto provide very inexpensive
solutions for the medicalindustry, and it wasn't what I
started out doing in my life.
I started out in the militarypretty much about a year out of
(04:43):
high school and spent someinteresting time in various
parts of the world.
I was actually someone whohunted submarines, so that was
an interesting component.
Flew in helicopters, huntedsubmarines, did a variety of
other things, and I found myselfin the middle of some times
(05:04):
that I didn't expect but glad tohave served.
While it wasn't technical as welook at it today, hunting
submarines in the militaryrequired a lot of technical
understanding, and so that kindof started me off on the
technical path, even though Itook my first programming class
in 1980, way before probablymost of your listeners were born
(05:30):
.
That being said, after that Igot out and I started going down
the technical path, startedeverything from consulting to
various small businesses thatI've owned, worked in fintech
for about 25 years.
Since that timeframe, mypartner and I, about seven years
(05:51):
ago, started working on AHvos.
It's very exciting for us to beable to bring this to the
market and look forward toseeing where it's going to go.
Debra J Farber (06:01):
I appreciate that.
That's super helpful.
The reason that you're on theshow is that you took a
particular privacy-relatedapproach.
I would love to hear about someof the issues you saw around AI
and privacy and what thatarchitectural approach is that
you took for AHvos.
I know you have severalproducts.
Maybe if it's at a higher-level philosophy or if you
(06:23):
wanted to go into yourapproaches to each product, I'll
leave it to you.
Kevin Killens (06:27):
We did take a privacy approach and it's very
important to us.
I'm a bit of a privacy hackmyself, because I don't believe
that people have a right to ourdata, our online personage, if
you will.
I think that it's veryimportant that, as the world
grows increasingly moreconnected, that the connection
(06:48):
is isolated to what we giveaccess to, not what we put
online.
I think there's a bigdifference between what we
actually agreed to give peopleaccess to and what they actually
access.
I'll give you a perfect example.
If you look at the EULAs - theEnd-User License Agreements - no
one ever reads those.
They're so long and obfuscatedand companies do that on purpose
(07:12):
so that you don't read them.
That's when they're able toadjust things.
What we did at AHvos.
We said, o"Okay, we're notgoing to do that.
We're actually going toestablish our engines, our
models, to where they don't takeadvantage of people's personal
data, where a company can beassured that their data is not
(07:32):
going to be shared with othercompanies or made a part of our
larger AI model.
" Our engines are designed to beable to learn concepts from
customer data.
They're not designed to keepthe customer data.
When a customer actuallyinjects data into our engine,
(07:56):
what they're doing is they'regiving our engine the capability
, or the opportunity, to learnfrom concepts.
Once we ingest that data, it'sgone.
We don't put it anywhere.
We don't keep it.
The reason for that is that'snot our data; it's the other
company's data.
I think, when it comes toarchitecting models that we need
(08:18):
to understand that we wouldwant our customers to have the
same security, the same privacythat we have and that we want.
It's just like the Golden Rule: do unto others as you would (08:30):
undefined
have them do unto you.
Debra J Farber (08:36):
It's not "extract all the monetary value
out of humans as much aspossible and track them all
across the world.
" It's not that.
Kevin Killens (08:44):
It's very much like The Matrix.
They look at us, instead of abattery, it's a data source.
They try to extract every bitout of us as they can.
So, anytime they have thatopportunity, I find it
interesting that many of thetech moguls don't allow their
children to get online.
[Debra (09:02):
Agreed] But, they have no problem doing that with our
data.
If you look, it's interestingthat when you say something,
that all of a sudden you haveads pop up in your social media,
et cetera, to find out what youwant or to promote something.
Well, we don't do that.
You own the engine that wecreate for you.
(09:25):
That engine is there to serveour customer.
In doing so, what we do is wemake sure that you have the
ability to use it for what youwant to use it for.
No one else at our company cansee any of the data once it's
processed.
It comes in, it gets processed.
We can't do anything with it,but our engine is then educated
(09:48):
to do what you want it to do inorder to be able to provide you
the answers you want.
Debra J Farber (09:54):
Could you unpack that a little bit for us?
It has to be still processingdata.
If you're ingesting it somehow,even though you're not storing
it, it's still going to besubject to data processing
regulations like the GDPR.
Right?
Kevin Killens (10:08):
But here's the important part about it.
It comes in, it gets processed.
You could take our engine.
You could look through thatengine ad nauseam.
You will never find anythingrelated to it.
You can't reverse engineer it.
We learn the concepts.
It's like if you were talkingto me about algebra.
There is a problem.
You can teach me concepts aboutalgebra without having to have
(10:31):
specific problems.
Debra J Farber (10:34):
That makes a lot of sense.
You're generalizing, almost -to make the context?
Kevin Killens (10:39):
For example, if I took and gave you a problem,
two sets of parents where youhave A and B and first and C and
D, and last.
Right?
Part of algebra is called'FOIL': First, Outer, Inner,
Last.
It's a way you multiply and youcome up with your various
different results sets.
Well, I can tell somebody FOIL,but they don't know that the
(11:01):
data is A, B, C, or D.
But if they see A, B, C, or D,they know how to act on it.
Therefore, our engineunderstands how to get the
results sets, but it doesn'tkeep the data.
Debra J Farber (11:15):
Do you create an ontology that overlays this, or
is it the AI itself?
Actually, we're going to getinto that, because I'm going to
ask you what is ContextuallyResponsive Intelligence?
I guess I'm going to ask youprematurely.
Since privacy is all aboutcontext, I definitely would love
to unpack this technology thatyou've put in the market.
Kevin Killens (11:39):
Sure, absolutely.
We have CRI and it isContextually Responsive
Intelligence.
The reason why we have that isbecause.
.
.look, I know all the rage isto have LLMs and to have
generative AI.
It's interesting becausegenerative AI can create a
document, but it doesn'tnecessarily mean that the
document's correct.
We've all heard the stories ofpeople who use one of the
(12:01):
various different generative AImodels and they used it for a
professional reason and it woundup biting them.
What we do is we say "wWhatwould you like to know?
Then they tell us.
Then we say, okay, great, sendus the data that you have.
Then we will extract from thatdata what you want to know,
(12:22):
based on how it's labeled, basedon a wide variety of things.
What's exciting about it isthat we give you the answers
you're looking for rather thanjust giving you an answer There
are a lot of, especiallygenerative AI, it will give you
an answer.
It may not be right, but it'llgive you an answer.
The great part about what wehave is we can actually ingest
(12:45):
the data.
Data comes in.
As it comes in, it doesmomentarily get placed in our
file, in a file, but it isconsumed as it is getting placed
there.
So, it's milliseconds that it'sactually sitting there.
Debra J Farber (13:02):
I'll just point out to the audience that, while
it doesn't take a company whowould be using your product out
of being subject to the GDPR ifit's being used in the EU, it's
still great because this is likesecurity for privacy.
You're reducing the attacksurface, you're making it near
(13:23):
impossible to gain access tothat raw data.
You're abstracting it out withthis Contextually Responsive
Intelligence.
So, I just wanted to make thatdistinction.
I wasn't trying to say it's badthat it captures the data for a
little bit, just that becauseit is processing data, if
there's personal data that'sbeing processed, it's still
(13:44):
gonna be subject to the GDPR ifit's in the EU, which again is
not a problem in and of itself.
Kevin Killens (13:49):
No, it's actually not, and we welcome that.
The reason why we welcome it iswe think transparency is key.
So, as we bring in data, whatwe do is we learn the concepts
that want to be done from that.
So, for example, let me giveyou an example.
Let's say you send us medicaldata.
Well, medical data is very -how do you put it?
(14:10):
- it's very recognizable to alarge degree.
When they start talking aboutusing words like 'oncology,'
they start using words like'symptoms,' et cetera.
There are large sets of wordsthat are used for the medical
community that you can identifythat as 'medical data.
' We can learn "Okay, this ismedical data" without having to
(14:33):
say "well, this patient had thiscondition and so therefore, we
know how to deal with that datawithout having to deal with the
specific patient and what datawas represented in that file or
in that data transmission fromthem.
Does that make sense?
Debra J Farber (14:52):
It does.
It does make sense.
It's almost a little bit likedata discovery platforms, how
they try to find what isstructured or unstructured data
across their environment, andfind the personal data or find
the medical data.
But here, you've got a flexibleplatform for - it sounds to me
at least - for a variety of usecases, clearly not the purpose
(15:16):
of only data discovery; buthere, specifically for AI rather
than for a GRC- style, find-all- the- data governance
purpose right here.
It sounds like you're doing itfor "hHow can you find and make
relevant that data in the momentfor what the person is
searching for?
Kevin Killens (15:34):
Absolutely.
So, for example, you may havedata where you're looking to
identify a particular item.
One of the things that we have,and we'll talk about this in a
moment, is the ability toidentify and correct inaccurate
dataset labels.
So, that's just a single use.
Other things are, for example,when you take a telephone
(15:58):
answering service, we canactually take data from them
saying "Here are our phone calls, and then what we can do is we
can actually take in, we cantake that information and then
find out what they wanna auditfrom, get examples of that, and
then we can then look at all oftheir phone calls and say "yYou
(16:19):
should audit this one, youshould audit this one.
" and then we can actually gothrough their entire list of
their entire sets of phone callsand be able to tell them these
don't meet your standards.
And right now that just isn'tpossible, especially in the
timeframe that we can do it in.
Debra J Farber (16:38):
Fascinating.
Okay, well, let's turn ourattention to a little bit around
AI model bias.
Typically, I stay on topic toprivacy as much as I can, but
because there's so much going onin the AI space with the
overlap, and because you havesuch an interesting solution
that deals with it, I'd love totalk a little bit about bias.
In your opinion, what's theleading cause or causes of AI
(17:02):
model bias?
Kevin Killens (17:04):
One of the things that we address in our CRIs, we
only use the customer data.
We don't have engines that havebeen trained on data, either
straight from the Internet orlarge Gutenberg project, only
type data.
There's a wide variety ofmodels out there that train
(17:26):
their engines or train theirmodels based on publicly-
available data, scraping theweb, and, as a result, it goes
into their model.
And, that is the base thatpeople use if they want to fine-
tune that model, if they want toobtain answers, especially in
(17:49):
the generative world.
The generative AI - what theydo is they actually take large
amounts of data to be able tocreate a language response; but
then, whenever you ask forsomething or you try to fine-
tune that, what happens is itactually dilutes whatever your
data is with the data that isalready in the model.
(18:12):
So, when it comes to model bias,we've all heard about the
various different models outthere that have a trillion
parameters.
Well, those parameters areactually set by machine, by
algorithm; but those algorithms,those machines, are adjusted by
(18:34):
humans.
So, it can be biased based onwhat those parameters are.
When you look at human- createdalgorithms to set the
parameters, then you canactually influence a generative
AI, or any AI, by adjusting howthose parameters are set.
(18:56):
In addition to that, you canactually put in, by putting in
tremendous amounts of data priorto the customer using it, it
can actually cause that model tobe biased based on the data
that you put in.
So if, for example, you havetwo different types of a cancer
(19:19):
treatments and one thegenerative AI or the AI model is
completely trained or primarilytrained on Type A treatment
versus Type B, then that modelwill be biased toward what it's
been trained on.
So there's more to training AIand educating our engines than
(19:42):
what people understand.
You will only get a compositeof what's been put in and so-.
Debra J Farber (19:51):
Garbage in, garbage out, as we hear yeah.
Kevin Killens (19:53):
Right! Garbage in , garbage out.
Then, the other component tothat is where's the oversight?
Who is watching how thesemodels are set up?
Who is monitoring whether ornot they're being intentionally
biased?
We all know that there areethics teams that have been laid
(20:14):
off right after enormous roundsof investments were made into
various different generative AIplatforms.
Whenever you see someonedisband an ethics team or an
oversight team, the firstquestion needs to be: "why?
Those are a variety of reasons,and it can be legitimate
(20:39):
reasons to do that, as long asyou replace it with another
model to ensure that you're notproviding biased answers.
One of the things that I thinkis important is, like I say,
transparency (20:52):
to let people know what you're doing.
We don't use data other thanthe data that the customer
provides.
Debra J Farber (21:01):
And this is stored in.
.
.
controlled, I should say, byyour customer.
Right?
Like the company.
.
.
or is this a managed servicethat AHvos would manage for them
?
Kevin Killens (21:12):
The data we receive comes directly from the
customer.
Debra J Farber (21:14):
My point is are you managing it on their behalf
and helping with the models, oris it controllable by them, with
them owning the access controlsand all that?
Kevin Killens (21:26):
It is.
We actually have our engines ina space on Trinsic.
Those environments arecontrolled by us.
What gets injected into thoseengines is controlled entirely
by the customer, because theyhave the data and they have
access to an API which theninjects that data into our
(21:49):
engine.
So, we don't.
.
.
it's not like we have their datasitting somewhere where they
then they tell us what to inject.
What they do is they send usthat data, we put that in, and
it only uses their data.
Now, we work with customers.
We have a business- to-business model that we have
(22:10):
right now.
Ultimately, we will go to theconsumer with an alternative to
our current LLM generative AIs;but, it too, will not not share
their data.
So, it's very important thatpeople understand that, and then
the customer can inject thatinformation in.
(22:32):
It gets digested.
We don't keep the data.
So, now they have this enginethat's in there, that they can
actually use to get the answersthat they want, but they don't
have to worry about.
"Well, what about my competitor?
Can they access my model?
No, they can't.
So it gives you the confidencethat your data is secure.
(22:52):
It's your own data.
Your privacy is maintained foryou.
Debra J Farber (22:58):
And that data is not going to go to train models
elsewhere.
Kevin Killens (23:01):
Absolutely not, absolutely not.
Each engine is its own entity.
Now, we can have our engineswork together, but if they do
work together, they only worktogether with the customers'
other engines (if they choose tohave additional engines).
So, we do not allow forcustomer engines to work with
outside engines.
Debra J Farber (23:22):
Okay, that makes sense.
Thanks for that.
I know a lot of people online,when I'm reading about AI, a lot
of it is through onlinereading, people are usually
talking about removing bias fromAI training data sets, but what
I've learned from you is thatthere's also a need to remove
that bias in AI testing datasets.
(23:43):
Tell us a little bit more aboutthat.
Why is that the case?
What could go wrong if youdon't de-bias the testing data
sets?
Kevin Killens (23:51):
Sure, absolutely.
Any data set, whether it be atraining data set or a testing
data set, needs to be asaccurate as possible, and here's
the key about AI.
AI takes enormous amounts ofdata.
Now, the great part about it iswe only need about 25% of the
data that other models need.
We're able to reach our pointwhere we can be accurate at
(24:16):
about a quarter of the way towhat they need.
A good example is we actuallytook the Amazon what they call
the 'speech mark,' or themulti-language Amazon response
corpus (and I may be mis-quotingthat), but the mark.
.
.
and then, what we do is we takethat data set - it's about
80,000 reviews from Amazon - andwe take that data set, and then
(24:41):
what we do is we actuallyinject that into our engine very
much like they did.
Well, they take an alreadytrained model and then they
trained this.
They took this trained model,which could have taken anywhere
from months to years to train;they inject the fine- tuning
data in about 80,000 records;and then, they run the test sets
(25:03):
in those test sets.
To do the test sets and thefine- tuning take them about 10
hours.
We take our same engine fromscratch.
We take our engine, which doesnot have any prior training; we
run the fine- tuning on it,which we only take about 20,000
(25:24):
records versus that 80,000; andthen, in addition to that, we
then run the test through.
We do that all in secondsversus 10 hours, which is a huge
opportunity when you look atneeding fast responses.
The key to getting accuracy ishaving accurate data.
(25:45):
So, we actually detected inthat particular data set that
there are some inaccuratelabeling for records.
And so, what we did was we'reable to take and identify where
that inaccuracy is at, and thenwe can also, should we choose
to, be able to correct thosesets.
So, the great part about it is,if you put test sets in that
(26:09):
are inaccurate and their modeldoesn't understand what those
test sets should be, they'restill going to give an answer,
but it could be very much aninaccurate answer.
So, it's critical that yourtest sets have as much accuracy
as possible so that you need toknow what the actual answer is.
(26:34):
i"Is this auditable or is itnot?
Well, if I put inaccurate datain my test set, I may come up
with saying it's auditable whenit shouldn't be, and what that
does is that then uses resourcesfrom that company to actually
do auditing that they don't needto do.
Or, on the converse, n"No, thisshouldn't be audited and
(26:56):
therefore they skip over it.
And now they have someone whois doing something incorrectly
in their staff who does thecalls specifically addressing
the telephone answering service,and that affects the results
for the customers that they have.
So, testing data sets, it's veryimportant to have.
(27:21):
The more accurate the data sets, the more accurate the
education or the training.
We can help customers out therewho have large data sets that
people use for either trainingor testing, and there are
companies who sell those.
We can help them correct someof the inaccuracies they have in
those sets so that we can allhave a better product out there.
(27:42):
We're not here to replaceanybody.
What we're here to do is tohelp the overall industry to
become better.
That's our tagline (27:52):
"better AI, making AI better.
Debra J Farber (27:56):
I like that.
That's actually something, youknow, you've got to put that on
a T-shirt because it's a goodline.
Tell us a little bit about theproduct that AHvos has: Data
Crucible, which is your solutionfor identifying and correcting
inaccurate data set labels.
Kevin Killens (28:14):
Sure.
Data Crucible has the abilityto, when you give us a data set,
for example, you'll say, "Okay,here's all the data and here's
the label we want" on somethinglike, for example, is this a
large, medium or small?
And inevitably, whenever wereceive data sets, there's going
to be some that you can justvisually see are wrong.
(28:38):
There's going to be some thatare accurate, obviously; the
more the better.
Then, there'll be some that areblank, because either it wasn't
labeled or you got skipped over, or maybe there was a flaw in
the process, whatever the casemay be.
What our system can do is itcan go, evaluate the set of
data, and say w"ell, this shouldbe a large and it says small,
(29:02):
this should be a large and it'sleft blank.
This could be a small and it'sdone large.
And then what we can do is wecan do one of a couple of things
we can automatically correctthose or label those for a
company.
Or, what we can do is we canactually take that data set and
say, h"Here are the ones that wediscovered have inaccuracies,
(29:24):
what would you like us to dowith them?
And give the customer theopportunity to correct their
data if they choose to.
Or, they say, "Well, that'ssuch a small percentage, we're
not worried about it.
In all reality, I would thinkthat that wouldn't be the case.
So, we give the customer theopportunity to act on their data
.
Once again, privacy.
(29:44):
We're not going toautomatically act on someone's
data unless they give us the goahead to do so.
It's important that peoplerespect other people's data.
If I gave you $100,000 and Isaid, h"Hey, I want you to hold
on to this for me, but you wentout and you shared that with a
(30:05):
bunch of people on the streets,I think that people could
understand that that would be agross misplacement of trust on
my part.
Well, it's even worse with data, because data is something that
can be used not only to affectpeople's lives, but affect
people's decision making thataffect others' lives, and so if
(30:27):
we're going to train, if we'regoing to test data on behalf of
the public or behalf of othercompanies, then we need to do
the best we can do in order tobe able to provide them what
they should feel is well-placedtrust, by giving them
opportunities to act on theirdata in the way they choose to
(30:51):
and also showing them anythingthat they may believe is
accurate when it's not, or viceversa.
Debra J Farber (30:58):
Thank you so much for that.
That's a great explanation.
What advice do you have for ouraudience of privacy engineers
as they tackle AI challenges intheir own organizations.
I define 'privacy engineers' asthose who work on privacy as
researchers, as designers,architects, developers, data
scientists - so a broadtechnology focus.
(31:21):
If there's any of those groupsthat you'd want to call out, or
just generally, what advicewould you have?
Kevin Killens (31:27):
Well, my first statement would be everyone is a
privacy engineer.
That's from the customer whoowns the data, all the way down
to the person who may beanswering a support call,
someone who may be actuallyaddressing the data, a
researcher, etc.
If you're not a privacyengineer, then you're part of
the problem, because, in the waythat AI works, everyone has the
(31:52):
opportunity, "when they seesomething, to say something.
So you're a privacy engineer;speak up.
It's really important.
One of the things that we havewithin our company, if anyone
sees something, it is theirresponsibility to say something,
and no one's going to get introuble for saying something in
(32:13):
our company.
Now, I understand that, moreoften than not, this is a
contentious aspect in the AIworld today.
Everything is about speed.
There was recently anannouncement made about a new
model by one of the majorcompanies, and then it was found
out that their model, theirdemo, was canned.
[Debra (32:35):
It was Google] Yeah, exactly.
So, that's a race to marketbefore you have a finished
product.
That's a race to market and, asa result, there's some scathing
responses out there.
We can't do that with people'sdata.
The reason we haven't come outwith our alternative to LLMs, so
(32:59):
to speak, is because there aresafeguards that we need to place
around that.
Debra J Farber (33:04):
And that should be in the MVP, right?
That shouldn't be in the "wWell, we'll race to market and see
what people think about it andthen we'll add controls later.
Kevin Killens (33:13):
It has to be in the MVP.
It can't be, and to that point,that's a great point that you
make, Debra, related to yourprivacy engineers.
What your discipline ensures isthat when an MVP comes out,
that it includes the privacy.
So many times what you see isthere is not privacy embedded in
(33:35):
with developers in the DevOpsroutine, and if you don't embed
privacy as a discipline there,it will not exist.
Debra J Farber (33:46):
A lot of the times, it's baked into the
architecture.
If you try to deal with itlater, you might have to rebuild
your entire architecture andtech stack and.
.
.
Kevin Killens (33:58):
You will.
That's what I was about to say.
We all know about 'technicaldebt.
' Every company out there hastechnical debt.
Technical debt is like thenational debt: it never gets
paid down.
The reason is because that debtis almost insurmountable for
companies.
In a fast-paced world, goingslow is going fast.
If you go slow, make sure thatprivacy is within your AI model
(34:24):
and architecture.
You will go fast in the endbecause you will not retread;
you will not have PR issues; youwill not have lawsuits around
your data privacy.
That is absolutely critical.
There are people out thereright now that are.
.
(34:44):
.
there's lawsuits going throughthe courts around data scraping,
around data leaks, and you areon the forefront.
You're on the edge of the knifeand that cutting edge that
keeps companies accountable forwhat they do.
Debra J Farber (35:02):
There must be so much pressure within, not just
privacy engineers, but engineersworking on AI generally, if
they work for large companiesthat are feeling like they're in
an arms race against oneanother with these different
models that they're coming outwith, especially generative AI,
then it's really hard to - I'mnot saying they shouldn't do it;
of course they should speak up- but, it's really hard to tell
(35:24):
everyone to slow down when thetrain has already left the
building.
You know?
But, I do agree with youbecause, like Dr.
Rumman Chowdhury says when shegives speeches on this topic:
it's like when you add breaks toa car.
Back when a car was beingdeveloped for the first time, by
adding breaks which slow youdown literally by design, you
(35:49):
actually drive faster becauseyou have trust in the system
that you're in.
You have trust that they'llwork when you need them; and
therefore, you trust yourself ingoing faster in that car.
So, I absolutely agree with you.
I've been repeating this.
This is not the first time I'vementioned that parable from Dr.
Chowdhury, on this show atleast; I think it's just the
(36:11):
perfect summation of what youjust said.
Even though you feel like youmight be going slower, if you're
adding privacy protections,security protections, you're
thinking about the long-term andother legal requirements,
copyright, whatever else is outthere.
If you're not thinking aboutthat holistically and building
(36:31):
that into the MVP, then eventhough you might have a lot of
traction up- front, like OpenAIdoes, you might not be ahead in
the long run because you won'tbe able to compete with
companies that can sell productsto enterprises that can assure
certain things.
Like we're not going to beingesting the wrong data; it's
(36:51):
going to be un- biased, you'vegot to threat model, and then
figure out how you're going totackle that.
But anyway, I'm pretty muchsaying, "I 100% agree with you.
" That's great advice.
Kevin Killens (37:03):
I appreciate it, because speed cannot offset
privacy.
You can't go into surgerysaying, y"ep, we're just going
to run through this; we're notgoing to think about
contamination, sterility, etc.
" If you do, the patient's goingto die.
That's what's going to happenwith us, if we do not understand
(37:24):
that without putting privacy atthe forefront of how we treat
our customers, customers willstop trusting us.
Debra J Farber (37:34):
That's true, especially in the enterprise
space, or I should say thebusiness space, compared to
consumers, because consumers canuse a lot of these LLMs for
personal purposes.
Maybe they don't know it at thebeginning, but eventually they
start to realize, "Oh, it's notalways accurate.
That could be a lesson learnedacross people across countries
(37:58):
that there are - I won't callthem hallucinations - there are
lies, there's straight out liesthat sometimes the responses
will give back.
That's something that canhandle, I think, a little lower
fidelity if it's going to helpyou as a personal assistant of
some sort.
But, if you've got a businessthat's making decisions about
people and other importantthings, you want to make sure
(38:23):
that that's accurate.
So, what I hear (and I'mwondering if you're hearing the
same thing) is that even thougheveryone and their brother has
been deep- diving into AI,trying different apps, using
different models and maybe intheir own companies, maybe
playing around and testing withsome things - what I'm hearing
is that very few large companieshave actually deployed some of
(38:47):
these generative AI models atleast.
Kevin Killens (38:49):
Absolutely.
Debra J Farber (38:50):
Because there's so much risk and they have to
first define what that is andthen figure out a way to address
it.
Then, it might be limiting bythe nature of how the generative
models ingest data in the firstplace.
Kevin Killens (39:05):
It is true.
The key is that most of thesecorporations don't even really
know how they want to use AI.
So, one of the great thingsthat we have with our partner,
Trinsic, is we actually sit downand discuss with them what are
the challenges they're runninginto and how can we solve them,
once again, contextually withwhat they need.
(39:25):
It does not clear us of what weneed to do just by telling
people "on't use this foranything important, which is
what the generative AI folks say.
You know, "this is just beta,or you know this isn't to be
used for anything that iscritical.
(39:46):
" People are going to do that,and we have to make sure that we
understand that we put out aproduct that could be used for
something serious; and if it'snot ready for that, then we need
to make sure that we protectour customers by helping to put
the security, and definitely theprivacy, around things.
Debra J Farber (40:09):
Makes a lot of sense to me.
Well, Kevin, how can peoplereach out to you?
What's the best way and what'syour website, some contact
information before we closetoday?
Kevin Killens (40:19):
You can reach us at www.
AHvos.
com and also at www.
T rinsicTechnologies.
com, which is our partner.
You'll be able to get to us.
We look forward to anyquestions people may have, any
opportunities that they feellike they see within their own
marketplace where we can helpthem.
Once again, it's important thatpeople understand we do put
(40:41):
privacy at the top of ourpriorities because without it
the rest of it's just a house ofcards.
Debra J Farber (40:48):
Well, Kevin.
Thank you so much for joiningus today on The Shifting Privacy
Left podcast.
Until next Tuesday, everyoneone will be back with engaging
content and another great guest.
Thanks for joining us this weekon Shifting Privacy Left.
Make sure to visit our website,shiftingprivacyleft.
com, where you can subscribe toupdates so you'll never miss a
(41:11):
show.
While you're at it, if youfound this episode valuable, go
ahead and share it with a friend, and if you're an engineer who
cares passionately about privacy, check out Privado: the
developer-friendly privacyplatform and sponsor of this
show.
To learn more, go to privado.
ai.
Be sure to tune in next Tuesdayfor a new episode.
(41:31):
Bye for now.
I think that it's very important that, as the
world grows increasingly moreconnected, that the connection
is isolated to what we giveaccess to, not what we put
online.
I think there's a bigdifference between what we
actually agreed to give peopleaccess to and what they actually
(00:20):
access.
I'll give you a perfectexample: if you look at the
EULAs - the End User LicenseAgreements - no one ever reads
those.
They're so long and obfuscatedand companies do that on purpose
so that you don't read them.
Debra J Farber (00:33):
Hello, I am Debra J Farber.
Welcome to The Shifting PrivacyLeft Podcast, where we talk
about embedding privacy bydesign and default into the
engineering function to preventprivacy harms to humans, and to
prevent dystopia.
Each week, we'll bring youunique discussions with global
privacy technologists andinnovators working at the
(00:54):
bleeding- edge of privacyresearch and emerging
technologies, standards,business models, and ecosystems.
Welcome everyone to ShiftingPrivacy Left.
I'm your Host and residentprivacy guru, Debra J Farber.
Today, I'm delighted to welcomemy next guest, Kevin Killins,
CEO of AHvos.
(01:14):
AHvos specializes in AIsolutions for data- heavy
businesses.
In a strategic partnership withTrinsic Technologies, AHvos
offers exclusive cloud hostingfor its private AI engines,
allowing businesses to havetheir own dedicated AI engines
powered by their own data.
According to Kevin, what setsAHvos apart is its proprietary
(01:36):
technology called 'ContextuallyResponsive Intelligence,' or CRI
.
Unlike traditional AI modelsthat rely on 'Large Language
Models' (or LLMs) and heavyneural networks, AHvos CRI
technology can act upon abusiness's private data and
produce results without storingthat data.
I'm really excited to divedeeper on this technology and
(02:00):
learn more from Kevin.
So, welcome Kevin.
Kevin Killens (02:03):
I appreciate it.
Thank you very much, Debra.
It's great to be here and lookforward to our session today.
Debra J Farber (02:09):
Excellent.
So, obviously, to start, Ithink it would be really helpful
for you to tell us a little bitabout AHvos t hat motivated you
to found this AI focusedcompany, and a little bit about
what your career trajectorylooks like?
I know you were in the Army orNavy.
You were in the military, right?
[Kevin (02:26):
Navy] Awesome.
Tell us a little bit.
Kevin Killens (02:31):
I was in the Navy .
This company is a very personaleffect for both my partner and
I and we're dedicated to it fora variety of reasons, obviously,
but we saw that there were alot of companies out there that
were performing AI and coming upwith various models.
Two things stuck out to us (02:50):
1) One was that the change in AI
was really not that significantsince the mid-century, last
century.
The main advancements that weremade were hardware and the
amount of digital data that wasavailable.
So, my partner and I said,"Okay, there's got to be a
better way of doing this.
(03:12):
So we started to look into itmore deeply, and the main reason
that we focused on it was thatwe both have family members that
had medical issues.
We wanted to find solutions formedical issues, and that's the
reason why we started workingwith the models that we have
(03:33):
with our engines.
Because those medical issueswere so personal to us, one of
the key elements was that themedical issues that we had
family members experience werenot very common medical issues.
We all know pharmaceuticalsfocus on the dollars, and so
(03:59):
smaller issues were not thingsthat they would place a lot of
heavy emphasis on.
So, we decided that we wouldcome up with a system that we
could address both the largelevel medical issues but also
the smaller, more niche or morerare conditions.
That's what kind of prompted usto start it.
As we started moving down thepath, we found that there were a
(04:23):
lot of commercial applicationsto what we do, and so we
obviously started working onthat path as well.
Our ultimate goal is to be ableto provide very inexpensive
solutions for the medicalindustry, and it wasn't what I
started out doing in my life.
I started out in the militarypretty much about a year out of
(04:43):
high school and spent someinteresting time in various
parts of the world.
I was actually someone whohunted submarines, so that was
an interesting component.
Flew in helicopters, huntedsubmarines, did a variety of
other things, and I found myselfin the middle of some times
(05:04):
that I didn't expect but glad tohave served.
While it wasn't technical as welook at it today, hunting
submarines in the militaryrequired a lot of technical
understanding, and so that kindof started me off on the
technical path, even though Itook my first programming class
in 1980, way before probablymost of your listeners were born
(05:30):
.
That being said, after that Igot out and I started going down
the technical path, startedeverything from consulting to
various small businesses thatI've owned, worked in fintech
for about 25 years.
Since that timeframe, mypartner and I, about seven years
(05:51):
ago, started working on AHvos.
It's very exciting for us to beable to bring this to the
market and look forward toseeing where it's going to go.
Debra J Farber (06:01):
I appreciate that.
That's super helpful.
The reason that you're on theshow is that you took a
particular privacy-relatedapproach.
I would love to hear about someof the issues you saw around AI
and privacy and what thatarchitectural approach is that
you took for AHvos.
I know you have severalproducts.
Maybe if it's at a higher-level philosophy or if you
(06:23):
wanted to go into yourapproaches to each product, I'll
leave it to you.
Kevin Killens (06:27):
We did take a privacy approach and it's very
important to us.
I'm a bit of a privacy hackmyself, because I don't believe
that people have a right to ourdata, our online personage, if
you will.
I think that it's veryimportant that, as the world
grows increasingly moreconnected, that the connection
(06:48):
is isolated to what we giveaccess to, not what we put
online.
I think there's a bigdifference between what we
actually agreed to give peopleaccess to and what they actually
access.
I'll give you a perfect example.
If you look at the EULAs - theEnd-User License Agreements - no
one ever reads those.
They're so long and obfuscatedand companies do that on purpose
(07:12):
so that you don't read them.
That's when they're able toadjust things.
What we did at AHvos.
We said, o"Okay, we're notgoing to do that.
We're actually going toestablish our engines, our
models, to where they don't takeadvantage of people's personal
data, where a company can beassured that their data is not
(07:32):
going to be shared with othercompanies or made a part of our
larger AI model.
" Our engines are designed to beable to learn concepts from
customer data.
They're not designed to keepthe customer data.
When a customer actuallyinjects data into our engine,
(07:56):
what they're doing is they'regiving our engine the capability
, or the opportunity, to learnfrom concepts.
Once we ingest that data, it'sgone.
We don't put it anywhere.
We don't keep it.
The reason for that is that'snot our data; it's the other
company's data.
I think, when it comes toarchitecting models that we need
(08:18):
to understand that we wouldwant our customers to have the
same security, the same privacythat we have and that we want.
It's just like the Golden Rule: do unto others as you would (08:30):
undefined
have them do unto you.
Debra J Farber (08:36):
It's not "extract all the monetary value
out of humans as much aspossible and track them all
across the world.
" It's not that.
Kevin Killens (08:44):
It's very much like The Matrix.
They look at us, instead of abattery, it's a data source.
They try to extract every bitout of us as they can.
So, anytime they have thatopportunity, I find it
interesting that many of thetech moguls don't allow their
children to get online.
[Debra (09:02):
Agreed] But, they have no problem doing that with our
data.
If you look, it's interestingthat when you say something,
that all of a sudden you haveads pop up in your social media,
et cetera, to find out what youwant or to promote something.
Well, we don't do that.
You own the engine that wecreate for you.
(09:25):
That engine is there to serveour customer.
In doing so, what we do is wemake sure that you have the
ability to use it for what youwant to use it for.
No one else at our company cansee any of the data once it's
processed.
It comes in, it gets processed.
We can't do anything with it,but our engine is then educated
(09:48):
to do what you want it to do inorder to be able to provide you
the answers you want.
Debra J Farber (09:54):
Could you unpack that a little bit for us?
It has to be still processingdata.
If you're ingesting it somehow,even though you're not storing
it, it's still going to besubject to data processing
regulations like the GDPR.
Right?
Kevin Killens (10:08):
But here's the important part about it.
It comes in, it gets processed.
You could take our engine.
You could look through thatengine ad nauseam.
You will never find anythingrelated to it.
You can't reverse engineer it.
We learn the concepts.
It's like if you were talkingto me about algebra.
There is a problem.
You can teach me concepts aboutalgebra without having to have
(10:31):
specific problems.
Debra J Farber (10:34):
That makes a lot of sense.
You're generalizing, almost -to make the context?
Kevin Killens (10:39):
For example, if I took and gave you a problem,
two sets of parents where youhave A and B and first and C and
D, and last.
Right?
Part of algebra is called'FOIL': First, Outer, Inner,
Last.
It's a way you multiply and youcome up with your various
different results sets.
Well, I can tell somebody FOIL,but they don't know that the
(11:01):
data is A, B, C, or D.
But if they see A, B, C, or D,they know how to act on it.
Therefore, our engineunderstands how to get the
results sets, but it doesn'tkeep the data.
Debra J Farber (11:15):
Do you create an ontology that overlays this, or
is it the AI itself?
Actually, we're going to getinto that, because I'm going to
ask you what is ContextuallyResponsive Intelligence?
I guess I'm going to ask youprematurely.
Since privacy is all aboutcontext, I definitely would love
to unpack this technology thatyou've put in the market.
Kevin Killens (11:39):
Sure, absolutely.
We have CRI and it isContextually Responsive
Intelligence.
The reason why we have that isbecause.
.
.look, I know all the rage isto have LLMs and to have
generative AI.
It's interesting becausegenerative AI can create a
document, but it doesn'tnecessarily mean that the
document's correct.
We've all heard the stories ofpeople who use one of the
(12:01):
various different generative AImodels and they used it for a
professional reason and it woundup biting them.
What we do is we say "wWhatwould you like to know?
Then they tell us.
Then we say, okay, great, sendus the data that you have.
Then we will extract from thatdata what you want to know,
(12:22):
based on how it's labeled, basedon a wide variety of things.
What's exciting about it isthat we give you the answers
you're looking for rather thanjust giving you an answer There
are a lot of, especiallygenerative AI, it will give you
an answer.
It may not be right, but it'llgive you an answer.
The great part about what wehave is we can actually ingest
(12:45):
the data.
Data comes in.
As it comes in, it doesmomentarily get placed in our
file, in a file, but it isconsumed as it is getting placed
there.
So, it's milliseconds that it'sactually sitting there.
Debra J Farber (13:02):
I'll just point out to the audience that, while
it doesn't take a company whowould be using your product out
of being subject to the GDPR ifit's being used in the EU, it's
still great because this is likesecurity for privacy.
You're reducing the attacksurface, you're making it near
(13:23):
impossible to gain access tothat raw data.
You're abstracting it out withthis Contextually Responsive
Intelligence.
So, I just wanted to make thatdistinction.
I wasn't trying to say it's badthat it captures the data for a
little bit, just that becauseit is processing data, if
there's personal data that'sbeing processed, it's still
(13:44):
gonna be subject to the GDPR ifit's in the EU, which again is
not a problem in and of itself.
Kevin Killens (13:49):
No, it's actually not, and we welcome that.
The reason why we welcome it iswe think transparency is key.
So, as we bring in data, whatwe do is we learn the concepts
that want to be done from that.
So, for example, let me giveyou an example.
Let's say you send us medicaldata.
Well, medical data is very -how do you put it?
(14:10):
- it's very recognizable to alarge degree.
When they start talking aboutusing words like 'oncology,'
they start using words like'symptoms,' et cetera.
There are large sets of wordsthat are used for the medical
community that you can identifythat as 'medical data.
' We can learn "Okay, this ismedical data" without having to
(14:33):
say "well, this patient had thiscondition and so therefore, we
know how to deal with that datawithout having to deal with the
specific patient and what datawas represented in that file or
in that data transmission fromthem.
Does that make sense?
Debra J Farber (14:52):
It does.
It does make sense.
It's almost a little bit likedata discovery platforms, how
they try to find what isstructured or unstructured data
across their environment, andfind the personal data or find
the medical data.
But here, you've got a flexibleplatform for - it sounds to me
at least - for a variety of usecases, clearly not the purpose
(15:16):
of only data discovery; buthere, specifically for AI rather
than for a GRC- style, find-all- the- data governance
purpose right here.
It sounds like you're doing itfor "hHow can you find and make
relevant that data in the momentfor what the person is
searching for?
Kevin Killens (15:34):
Absolutely.
So, for example, you may havedata where you're looking to
identify a particular item.
One of the things that we have,and we'll talk about this in a
moment, is the ability toidentify and correct inaccurate
dataset labels.
So, that's just a single use.
Other things are, for example,when you take a telephone
(15:58):
answering service, we canactually take data from them
saying "Here are our phone calls, and then what we can do is we
can actually take in, we cantake that information and then
find out what they wanna auditfrom, get examples of that, and
then we can then look at all oftheir phone calls and say "yYou
(16:19):
should audit this one, youshould audit this one.
" and then we can actually gothrough their entire list of
their entire sets of phone callsand be able to tell them these
don't meet your standards.
And right now that just isn'tpossible, especially in the
timeframe that we can do it in.
Debra J Farber (16:38):
Fascinating.
Okay, well, let's turn ourattention to a little bit around
AI model bias.
Typically, I stay on topic toprivacy as much as I can, but
because there's so much going onin the AI space with the
overlap, and because you havesuch an interesting solution
that deals with it, I'd love totalk a little bit about bias.
In your opinion, what's theleading cause or causes of AI
(17:02):
model bias?
Kevin Killens (17:04):
One of the things that we address in our CRIs, we
only use the customer data.
We don't have engines that havebeen trained on data, either
straight from the Internet orlarge Gutenberg project, only
type data.
There's a wide variety ofmodels out there that train
(17:26):
their engines or train theirmodels based on publicly-
available data, scraping theweb, and, as a result, it goes
into their model.
And, that is the base thatpeople use if they want to fine-
tune that model, if they want toobtain answers, especially in
(17:49):
the generative world.
The generative AI - what theydo is they actually take large
amounts of data to be able tocreate a language response; but
then, whenever you ask forsomething or you try to fine-
tune that, what happens is itactually dilutes whatever your
data is with the data that isalready in the model.
(18:12):
So, when it comes to model bias,we've all heard about the
various different models outthere that have a trillion
parameters.
Well, those parameters areactually set by machine, by
algorithm; but those algorithms,those machines, are adjusted by
(18:34):
humans.
So, it can be biased based onwhat those parameters are.
When you look at human- createdalgorithms to set the
parameters, then you canactually influence a generative
AI, or any AI, by adjusting howthose parameters are set.
(18:56):
In addition to that, you canactually put in, by putting in
tremendous amounts of data priorto the customer using it, it
can actually cause that model tobe biased based on the data
that you put in.
So if, for example, you havetwo different types of a cancer
(19:19):
treatments and one thegenerative AI or the AI model is
completely trained or primarilytrained on Type A treatment
versus Type B, then that modelwill be biased toward what it's
been trained on.
So there's more to training AIand educating our engines than
(19:42):
what people understand.
You will only get a compositeof what's been put in and so-.
Debra J Farber (19:51):
Garbage in, garbage out, as we hear yeah.
Kevin Killens (19:53):
Right! Garbage in , garbage out.
Then, the other component tothat is where's the oversight?
Who is watching how thesemodels are set up?
Who is monitoring whether ornot they're being intentionally
biased?
We all know that there areethics teams that have been laid
(20:14):
off right after enormous roundsof investments were made into
various different generative AIplatforms.
Whenever you see someonedisband an ethics team or an
oversight team, the firstquestion needs to be: "why?
Those are a variety of reasons,and it can be legitimate
(20:39):
reasons to do that, as long asyou replace it with another
model to ensure that you're notproviding biased answers.
One of the things that I thinkis important is, like I say,
transparency (20:52):
to let people know what you're doing.
We don't use data other thanthe data that the customer
provides.
Debra J Farber (21:01):
And this is stored in.
.
.
controlled, I should say, byyour customer.
Right?
Like the company.
.
.
or is this a managed servicethat AHvos would manage for them
?
Kevin Killens (21:12):
The data we receive comes directly from the
customer.
Debra J Farber (21:14):
My point is are you managing it on their behalf
and helping with the models, oris it controllable by them, with
them owning the access controlsand all that?
Kevin Killens (21:26):
It is.
We actually have our engines ina space on Trinsic.
Those environments arecontrolled by us.
What gets injected into thoseengines is controlled entirely
by the customer, because theyhave the data and they have
access to an API which theninjects that data into our
(21:49):
engine.
So, we don't.
.
.
it's not like we have their datasitting somewhere where they
then they tell us what to inject.
What they do is they send usthat data, we put that in, and
it only uses their data.
Now, we work with customers.
We have a business- to-business model that we have
(22:10):
right now.
Ultimately, we will go to theconsumer with an alternative to
our current LLM generative AIs;but, it too, will not not share
their data.
So, it's very important thatpeople understand that, and then
the customer can inject thatinformation in.
(22:32):
It gets digested.
We don't keep the data.
So, now they have this enginethat's in there, that they can
actually use to get the answersthat they want, but they don't
have to worry about.
"Well, what about my competitor?
Can they access my model?
No, they can't.
So it gives you the confidencethat your data is secure.
(22:52):
It's your own data.
Your privacy is maintained foryou.
Debra J Farber (22:58):
And that data is not going to go to train models
elsewhere.
Kevin Killens (23:01):
Absolutely not, absolutely not.
Each engine is its own entity.
Now, we can have our engineswork together, but if they do
work together, they only worktogether with the customers'
other engines (if they choose tohave additional engines).
So, we do not allow forcustomer engines to work with
outside engines.
Debra J Farber (23:22):
Okay, that makes sense.
Thanks for that.
I know a lot of people online,when I'm reading about AI, a lot
of it is through onlinereading, people are usually
talking about removing bias fromAI training data sets, but what
I've learned from you is thatthere's also a need to remove
that bias in AI testing datasets.
(23:43):
Tell us a little bit more aboutthat.
Why is that the case?
What could go wrong if youdon't de-bias the testing data
sets?
Kevin Killens (23:51):
Sure, absolutely.
Any data set, whether it be atraining data set or a testing
data set, needs to be asaccurate as possible, and here's
the key about AI.
AI takes enormous amounts ofdata.
Now, the great part about it iswe only need about 25% of the
data that other models need.
We're able to reach our pointwhere we can be accurate at
(24:16):
about a quarter of the way towhat they need.
A good example is we actuallytook the Amazon what they call
the 'speech mark,' or themulti-language Amazon response
corpus (and I may be mis-quotingthat), but the mark.
.
.
and then, what we do is we takethat data set - it's about
80,000 reviews from Amazon - andwe take that data set, and then
(24:41):
what we do is we actuallyinject that into our engine very
much like they did.
Well, they take an alreadytrained model and then they
trained this.
They took this trained model,which could have taken anywhere
from months to years to train;they inject the fine- tuning
data in about 80,000 records;and then, they run the test sets
(25:03):
in those test sets.
To do the test sets and thefine- tuning take them about 10
hours.
We take our same engine fromscratch.
We take our engine, which doesnot have any prior training; we
run the fine- tuning on it,which we only take about 20,000
(25:24):
records versus that 80,000; andthen, in addition to that, we
then run the test through.
We do that all in secondsversus 10 hours, which is a huge
opportunity when you look atneeding fast responses.
The key to getting accuracy ishaving accurate data.
(25:45):
So, we actually detected inthat particular data set that
there are some inaccuratelabeling for records.
And so, what we did was we'reable to take and identify where
that inaccuracy is at, and thenwe can also, should we choose
to, be able to correct thosesets.
So, the great part about it is,if you put test sets in that
(26:09):
are inaccurate and their modeldoesn't understand what those
test sets should be, they'restill going to give an answer,
but it could be very much aninaccurate answer.
So, it's critical that yourtest sets have as much accuracy
as possible so that you need toknow what the actual answer is.
(26:34):
i"Is this auditable or is itnot?
Well, if I put inaccurate datain my test set, I may come up
with saying it's auditable whenit shouldn't be, and what that
does is that then uses resourcesfrom that company to actually
do auditing that they don't needto do.
Or, on the converse, n"No, thisshouldn't be audited and
(26:56):
therefore they skip over it.
And now they have someone whois doing something incorrectly
in their staff who does thecalls specifically addressing
the telephone answering service,and that affects the results
for the customers that they have.
So, testing data sets, it's veryimportant to have.
(27:21):
The more accurate the data sets, the more accurate the
education or the training.
We can help customers out therewho have large data sets that
people use for either trainingor testing, and there are
companies who sell those.
We can help them correct someof the inaccuracies they have in
those sets so that we can allhave a better product out there.
(27:42):
We're not here to replaceanybody.
What we're here to do is tohelp the overall industry to
become better.
That's our tagline (27:52):
"better AI, making AI better.
Debra J Farber (27:56):
I like that.
That's actually something, youknow, you've got to put that on
a T-shirt because it's a goodline.
Tell us a little bit about theproduct that AHvos has: Data
Crucible, which is your solutionfor identifying and correcting
inaccurate data set labels.
Kevin Killens (28:14):
Sure.
Data Crucible has the abilityto, when you give us a data set,
for example, you'll say, "Okay,here's all the data and here's
the label we want" on somethinglike, for example, is this a
large, medium or small?
And inevitably, whenever wereceive data sets, there's going
to be some that you can justvisually see are wrong.
(28:38):
There's going to be some thatare accurate, obviously; the
more the better.
Then, there'll be some that areblank, because either it wasn't
labeled or you got skipped over, or maybe there was a flaw in
the process, whatever the casemay be.
What our system can do is itcan go, evaluate the set of
data, and say w"ell, this shouldbe a large and it says small,
(29:02):
this should be a large and it'sleft blank.
This could be a small and it'sdone large.
And then what we can do is wecan do one of a couple of things
we can automatically correctthose or label those for a
company.
Or, what we can do is we canactually take that data set and
say, h"Here are the ones that wediscovered have inaccuracies,
(29:24):
what would you like us to dowith them?
And give the customer theopportunity to correct their
data if they choose to.
Or, they say, "Well, that'ssuch a small percentage, we're
not worried about it.
In all reality, I would thinkthat that wouldn't be the case.
So, we give the customer theopportunity to act on their data
.
Once again, privacy.
(29:44):
We're not going toautomatically act on someone's
data unless they give us the goahead to do so.
It's important that peoplerespect other people's data.
If I gave you $100,000 and Isaid, h"Hey, I want you to hold
on to this for me, but you wentout and you shared that with a
(30:05):
bunch of people on the streets,I think that people could
understand that that would be agross misplacement of trust on
my part.
Well, it's even worse with data, because data is something that
can be used not only to affectpeople's lives, but affect
people's decision making thataffect others' lives, and so if
(30:27):
we're going to train, if we'regoing to test data on behalf of
the public or behalf of othercompanies, then we need to do
the best we can do in order tobe able to provide them what
they should feel is well-placedtrust, by giving them
opportunities to act on theirdata in the way they choose to
(30:51):
and also showing them anythingthat they may believe is
accurate when it's not, or viceversa.
Debra J Farber (30:58):
Thank you so much for that.
That's a great explanation.
What advice do you have for ouraudience of privacy engineers
as they tackle AI challenges intheir own organizations.
I define 'privacy engineers' asthose who work on privacy as
researchers, as designers,architects, developers, data
scientists - so a broadtechnology focus.
(31:21):
If there's any of those groupsthat you'd want to call out, or
just generally, what advicewould you have?
Kevin Killens (31:27):
Well, my first statement would be everyone is a
privacy engineer.
That's from the customer whoowns the data, all the way down
to the person who may beanswering a support call,
someone who may be actuallyaddressing the data, a
researcher, etc.
If you're not a privacyengineer, then you're part of
the problem, because, in the waythat AI works, everyone has the
(31:52):
opportunity, "when they seesomething, to say something.
So you're a privacy engineer;speak up.
It's really important.
One of the things that we havewithin our company, if anyone
sees something, it is theirresponsibility to say something,
and no one's going to get introuble for saying something in
(32:13):
our company.
Now, I understand that, moreoften than not, this is a
contentious aspect in the AIworld today.
Everything is about speed.
There was recently anannouncement made about a new
model by one of the majorcompanies, and then it was found
out that their model, theirdemo, was canned.
[Debra (32:35):
It was Google] Yeah, exactly.
So, that's a race to marketbefore you have a finished
product.
That's a race to market and, asa result, there's some scathing
responses out there.
We can't do that with people'sdata.
The reason we haven't come outwith our alternative to LLMs, so
(32:59):
to speak, is because there aresafeguards that we need to place
around that.
Debra J Farber (33:04):
And that should be in the MVP, right?
That shouldn't be in the "wWell, we'll race to market and see
what people think about it andthen we'll add controls later.
Kevin Killens (33:13):
It has to be in the MVP.
It can't be, and to that point,that's a great point that you
make, Debra, related to yourprivacy engineers.
What your discipline ensures isthat when an MVP comes out,
that it includes the privacy.
So many times what you see isthere is not privacy embedded in
(33:35):
with developers in the DevOpsroutine, and if you don't embed
privacy as a discipline there,it will not exist.
Debra J Farber (33:46):
A lot of the times, it's baked into the
architecture.
If you try to deal with itlater, you might have to rebuild
your entire architecture andtech stack and.
.
.
Kevin Killens (33:58):
You will.
That's what I was about to say.
We all know about 'technicaldebt.
' Every company out there hastechnical debt.
Technical debt is like thenational debt: it never gets
paid down.
The reason is because that debtis almost insurmountable for
companies.
In a fast-paced world, goingslow is going fast.
If you go slow, make sure thatprivacy is within your AI model
(34:24):
and architecture.
You will go fast in the endbecause you will not retread;
you will not have PR issues; youwill not have lawsuits around
your data privacy.
That is absolutely critical.
There are people out thereright now that are.
.
(34:44):
.
there's lawsuits going throughthe courts around data scraping,
around data leaks, and you areon the forefront.
You're on the edge of the knifeand that cutting edge that
keeps companies accountable forwhat they do.
Debra J Farber (35:02):
There must be so much pressure within, not just
privacy engineers, but engineersworking on AI generally, if
they work for large companiesthat are feeling like they're in
an arms race against oneanother with these different
models that they're coming outwith, especially generative AI,
then it's really hard to - I'mnot saying they shouldn't do it;
of course they should speak up- but, it's really hard to tell
(35:24):
everyone to slow down when thetrain has already left the
building.
You know?
But, I do agree with youbecause, like Dr.
Rumman Chowdhury says when shegives speeches on this topic:
it's like when you add breaks toa car.
Back when a car was beingdeveloped for the first time, by
adding breaks which slow youdown literally by design, you
(35:49):
actually drive faster becauseyou have trust in the system
that you're in.
You have trust that they'llwork when you need them; and
therefore, you trust yourself ingoing faster in that car.
So, I absolutely agree with you.
I've been repeating this.
This is not the first time I'vementioned that parable from Dr.
Chowdhury, on this show atleast; I think it's just the
(36:11):
perfect summation of what youjust said.
Even though you feel like youmight be going slower, if you're
adding privacy protections,security protections, you're
thinking about the long-term andother legal requirements,
copyright, whatever else is outthere.
If you're not thinking aboutthat holistically and building
(36:31):
that into the MVP, then eventhough you might have a lot of
traction up- front, like OpenAIdoes, you might not be ahead in
the long run because you won'tbe able to compete with
companies that can sell productsto enterprises that can assure
certain things.
Like we're not going to beingesting the wrong data; it's
(36:51):
going to be un- biased, you'vegot to threat model, and then
figure out how you're going totackle that.
But anyway, I'm pretty muchsaying, "I 100% agree with you.
" That's great advice.
Kevin Killens (37:03):
I appreciate it, because speed cannot offset
privacy.
You can't go into surgerysaying, y"ep, we're just going
to run through this; we're notgoing to think about
contamination, sterility, etc.
" If you do, the patient's goingto die.
That's what's going to happenwith us, if we do not understand
(37:24):
that without putting privacy atthe forefront of how we treat
our customers, customers willstop trusting us.
Debra J Farber (37:34):
That's true, especially in the enterprise
space, or I should say thebusiness space, compared to
consumers, because consumers canuse a lot of these LLMs for
personal purposes.
Maybe they don't know it at thebeginning, but eventually they
start to realize, "Oh, it's notalways accurate.
That could be a lesson learnedacross people across countries
(37:58):
that there are - I won't callthem hallucinations - there are
lies, there's straight out liesthat sometimes the responses
will give back.
That's something that canhandle, I think, a little lower
fidelity if it's going to helpyou as a personal assistant of
some sort.
But, if you've got a businessthat's making decisions about
people and other importantthings, you want to make sure
(38:23):
that that's accurate.
So, what I hear (and I'mwondering if you're hearing the
same thing) is that even thougheveryone and their brother has
been deep- diving into AI,trying different apps, using
different models and maybe intheir own companies, maybe
playing around and testing withsome things - what I'm hearing
is that very few large companieshave actually deployed some of
(38:47):
these generative AI models atleast.
Kevin Killens (38:49):
Absolutely.
Debra J Farber (38:50):
Because there's so much risk and they have to
first define what that is andthen figure out a way to address
it.
Then, it might be limiting bythe nature of how the generative
models ingest data in the firstplace.
Kevin Killens (39:05):
It is true.
The key is that most of thesecorporations don't even really
know how they want to use AI.
So, one of the great thingsthat we have with our partner,
Trinsic, is we actually sit downand discuss with them what are
the challenges they're runninginto and how can we solve them,
once again, contextually withwhat they need.
(39:25):
It does not clear us of what weneed to do just by telling
people "on't use this foranything important, which is
what the generative AI folks say.
You know, "this is just beta,or you know this isn't to be
used for anything that iscritical.
(39:46):
" People are going to do that,and we have to make sure that we
understand that we put out aproduct that could be used for
something serious; and if it'snot ready for that, then we need
to make sure that we protectour customers by helping to put
the security, and definitely theprivacy, around things.
Debra J Farber (40:09):
Makes a lot of sense to me.
Well, Kevin, how can peoplereach out to you?
What's the best way and what'syour website, some contact
information before we closetoday?
Kevin Killens (40:19):
You can reach us at www.
AHvos.
com and also at www.
T rinsicTechnologies.
com, which is our partner.
You'll be able to get to us.
We look forward to anyquestions people may have, any
opportunities that they feellike they see within their own
marketplace where we can helpthem.
Once again, it's important thatpeople understand we do put
(40:41):
privacy at the top of ourpriorities because without it
the rest of it's just a house ofcards.
Debra J Farber (40:48):
Well, Kevin.
Thank you so much for joiningus today on The Shifting Privacy
Left podcast.
Until next Tuesday, everyoneone will be back with engaging
content and another great guest.
Thanks for joining us this weekon Shifting Privacy Left.
Make sure to visit our website,shiftingprivacyleft.
com, where you can subscribe toupdates so you'll never miss a
(41:11):
show.
While you're at it, if youfound this episode valuable, go
ahead and share it with a friend, and if you're an engineer who
cares passionately about privacy, check out Privado: the
developer-friendly privacyplatform and sponsor of this
show.
To learn more, go to privado.
ai.
Be sure to tune in next Tuesdayfor a new episode.
(41:31):
Bye for now.
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com